Thanks for the advice, I've heard the same thing about Crestron writing a crappy module for it. I talked with a guy from Interactive technologies that said he was getting his hands on a crestron processor so they could write their own module for it.
Unfortunately I'm working with the Cueserver express, which doesn't have the RS232 capability, only IP. I might just try talking interactive into some sort of upgrade/exchange. Only being able to trigger cues sucks, my users want faders.
-Scott
toggle quoted message
Show quoted text
--- In Crestron@..., "mcqsack" <mqsack@...> wrote:
I fixed it by moving to serial. They actually sent us a new unit and we were having the same issue. Further investigation determined that the unit was actually falling off the network, not just losing connection with the Crestron proc. Turns out the RJ45 jacks on the units we had were slightly too big for most cables and they were not seating correctly. Moving to a sheilded cable with a thicker padding helped, but in the end we were not comfortable with this fix so we moved to RS232. You'll have to source that crazy 40 pin <> DB9 adapter if it didn't come with one.
I'd ditch the official module. According to the IT guys, it was half baked by Crestron and they failed to finish. It's one-way anyway, so there is no real benefit. Just use and SIO instead (or a few if you want to break out your commands by area). Keep in mind that the commands for RS232 need to be formatted differently. You need [] brackets around them. No delimiter is needed.
The protocol is clearly defined and easy to work with. One hint for smooth dimming is to utilize the @P1 command to stop a ramp. For example:
Dim Up:
[t5u4@90]
(Ramp group 4 to 90% over 5 seconds)
Run your press through a NTG symbol and have the output land on the SIO with this command:
[t0u4@P1]
Essentially telling the unit to immediately(t0) set group 4 (u4) to the current level of Playback fader 1 (P1). In other words "set yourself to the level you are at right now".
Similarly, Dim Down would be: [t5u4@0]
Besides hardware issues, I found the Cueserver environment an easy one to work in and the installation has run successfully for 2 years now.
HTH,
Matt
--- In Crestron@..., "scurrington1" <scurrington1@> wrote:
I'm having the same issue. Did you ever find any fix for this? I talked with some people at Interactive, they say that crestron wrote a bad driver for them and refuse to work with interactive to fix it.
-Scott
--- In Crestron@..., "mcqsack" <mqsack@> wrote:
Can anybody shed some light on what might be causing the following errors? This is a Simpl+ direct socket module written by Crestron, so I don't think it's OK to post the Simpl+ code here....but it is a IPM - (Interactive Technologies CueServer)...
20. Error: CSplusClientServerDriver::ConnectClient: Client connection already in progress
TimeStamp: 22:39:22 3-17-11 UpTime: 0 days 02:14:14.54 Task: S021000
21. Notice: SIMPL+ TCP Client __CUESERVER in module S-6.1:S-1: Unable to connect to TCP server (10.32.2.32), status = -257
TimeStamp: 22:39:23 3-17-11 UpTime: 0 days 02:14:15.83 Task: S+_CONN
22. Notice: SIMPL+ TCP Client __CUESERVER in module S-6.1:S-1: Unable to connect to TCP server (10.32.2.32), status = -257
TimeStamp: 22:39:32 3-17-11 UpTime: 0 days 02:14:24.02 Task: S+_CONN
23. Notice: SIMPL+ TCP Client __CUESERVER in module S-6.1:S-1: Unable to connect to TCP server (10.32.2.32), status = -257
TimeStamp: 22:39:50 3-17-11 UpTime: 0 days 02:14:41.53 Task: S+_CONN
I'm wondering about the "already in progress error". I was able to regain control sometimes by rebooting the Pro2, but recently I actually had to hard reset the actual Cue Server box.
Thanks...
MC
