Sea World needs help!

[Rickatsea]

Ken,

You get the tickets! If you are ever in San Diego, send me an email and I'll hook you up. Your last post is exactly what I'm looking for. Obviously my stakes are not that high. I can always fall back on the method we have been using for several years now. Before reading your last post I looked up the DF-1 protocols doc and found I lot of useful info. My show control system is fairly open ended. I have full control over the serial port and what I want to put on it, so that end of the comms is easy. What to do on the SLC side is where the light is not so bright so to speak.

Email to follow in private.

 

[Jason Valenzuela]

Well, you've hit on a little interest of mine. We do a LOT of A/V and show control work with AB PLCs for theme parks here in FL, and have learned a few tricks. First of all, usually show control systems need a reasonable amount of timing accuracy, within a frame is usually acceptable. Now consider that you are going to line up two asynchronous processors(your PC and the PLC) interconnected by communications link that is synchronous to neither of the above. Depending on scan rates and such, this can lead to your show timings drifting around.

That being said, we usually avoid this kind of thing except for very complex show control applications which require synchronization to external systems(such as video, SMPTE timecode, etc). We've implemented standalone PLC show control systems of moderate complexity completely within PLCs with excellent success.

Keep the tickets, working in them so much I never go to theme parks any more....

 

[Jason Valenzuela]

A quick note about implementing 'simple' ASCII protocols. If you exclude all the checksums/retries/etc that make reliable link layer protocols(DF1 for example), well, reliable but complex, you end up being very vulnerable to communication errors, which *WILL* happen. While this(I hope) isn't life safety, but a single wrong bit can burn your entire show, and possibly require restart/reboots depending on how well the parsers are written. IOW, if you aren't going to create or use a bullet proof protocol, hardwire == good.

 

[Rickatsea]

Thanks Jason.



We will be using a Granite Precision show control system. This PC based system is extremely fast and accurate down to a frame. Timing is a critical feature in this show as we have to pulse hundreds of mechanical relays which in turn are firing off air valves, solenoids and seat buzzers etc.. Of course this is all SMTPE driven and timed to reasonably match what is happening on screen. I’m fairly confident I can get the Granite Precision to stay on task. Hopefully the SLC serial ASCII will turn out to be fast and reliable enough providing I can make it work (with my limited SLC experience) in the first place. The response to my post has been overwhelming. This community is great! Thanks to folks like you!

 

[kamenges]

I don't think you will be able to get the results out of the ASCII serial transmission that you hope to get. I don't think it can be made bulletproof enough. Although, I have been wrong before.

If all you are looking for is an 8-bit action code, why not send eight hardwire lines from your computer to the SLC and send the code that way?

Keith

 

[Jason Valenzuela]

Ya, I've used Granite products before and worked with Jeff. Even though the PC is plenty fast, you're still limited by the communication rate and PLC scan rate. Since they are async, worst case is the sum of the two. FYI there are 3rd products out there that allow your SLC to read SMTPE timecode directly.

 

[CroCop]

I don't think you will be able to get the results out of the ASCII serial transmission that you hope to get. I don't think it can be made bulletproof enough. Although, I have been wrong before.

If all you are looking for is an 8-bit action code, why not send eight hardwire lines from your computer to the SLC and send the code that way?

Keith

This gets my vote.
An multi conductor shielded cable ran to the SLC to a single input card.

One could do some VERY simple & decently fast & easy to use things with a 16 input card & a bit of programming.

 

[davidg68124]

I will be in Sandiego next Wednesday. I would be happy to help you. I am an old SLC programmer and know alot of tricks. I would like to know a little more of what you have. Everything that has been posted is correct. If you need critical timing, serial will not be your best bet. But, maybe I can give you some guidance and help with the coding aspect.


My wife, 8 yo son, and I am flying in for my older son's Marine Boot Camp Graduation.

Contact me if you would like direct help with this. I would do it for the price of admission.

Regards,
David R. Gulick
Senior Controls Engineer
Engineering Automation & Design, Inc.
4610 South 133rd Street
Suite 106
Omaha, NE 68137



office: (402) 884-8650
fax: (402) 884-8651
cell: (402) 990-5311

 

[Jason Valenzuela]

If each line had a dedicated function, yes. If you're trying to make a parallel port, you'll need a strobe and handshake. That will also be pretty solid however it can quickly become a bottleneck if you're trying to push through a lot of commands quickly. Each command/handshake cycle can easily add up to 4 or more PLC scans(every transition detection is 2 scans until the output result), worst case, not including PC response time. Add to this the need to buffer commands on the PC side and the rabbit hole gets deep quick.

 

[davidg68124]

I ran across some info on a freely distributed DF-1 driver that might be of help.

Regards,
David R. Gulick
Senior Controls Engineer
Engineering Automation & Design, Inc.
4610 South 133rd Street
Suite 106
Omaha, NE 68137



office: (402) 884-8650
fax: (402) 884-8651
cell: (402) 990-5311