Programming over 9600baud ethernet radio?

OK, I've come full circle on my telemetry. Pipe dreams of 100mb 23ghz links to each remote station has been beaten down to 9600 baud routable Ethernet radio in the 450mhz range. Topology is just insurmountable.
9600 is fine for my data needs but I do have the desire to program over these links occasionally. The PLC's will be micrologic through compactlogic all ethernet of course.

The radios are transparent and essentially become a cable replacement.

Those of you with longer tooth than I ... will I have any luck programming over a link such as this? Assuming the link is solid.

I have done it with a 56K dial up modem
slow but no problem got the job done

The DH+ link I use on the old PLC-5's is 56K and that is not a problem, but this is 9600.... Over radio.
I'm expecting slow, but I'm more concerned with it being possible.

I'm relatively new to PLC programming, but this sounds very similar to a site I am currently working on (only difference being the PLC).

It’s going to take a while (compared to a hardwire connection) but it will work.

Earlier this year I was working on a system with several remote CompactLogix controllers, and attempted to program over the radio link (radios typically provided ~11KBps). Unfortunately, it didn't work very well and I ended up giving up the whole thought and instead would just drive out to the remote sites. Why? A few reasons:

1. Sending a program update to the remote site took several minutes, and it was mindnumbingly slow.

2. If the radio link dropped at any point during the transfer, you could brick your remote PLC. I say this more of a cautionary tale since I never bricked a CompactLogix controller completely, but I did have a few interrupted transfers that required me to drive out to the remote site and reload everything manually.

3. The problem with low bandwidth radios is that they're pretty sensitive to bandwidth, but more so than just being "slow". The radios I was using would crash if the amount of data was too large; the radios would just transfer as fast as they could, but then the link would get saturated, and the link would crash (as in, too many people trying to push their way through a door all at once). Then as traffic slowed down, the link would re-establish, the data would start flowing again, and then due to saturation the link would crash yet again. Unless there's a way to "throttle down" your ethernet connection, my guess is that you're going to experience the same as me.

4. Another issue I noticed was that any ancillary data that my laptop was broadcasting on the network would eventually try to broadcast through the radio since to the laptop, the "long ethernet cable" that is your radio connection is just that. So then THAT would crash the connection. Eventually we had to push the radios on their own segregated VLAN, and allow only the master comms PLC to use the connection. It was a HUGE frustration. So word to the wise, make sure your network traffic doesn't try to go through your ethernet radio connection!

Describe your network.

We use wireless access points through out the plant, but nothing is that slow.

james

It's definitely possible, I've done it in the past, but as other folks have posted, it will take a while and if the link is flaky at all, expected frequent dropouts. Also, don't expect anything else to happen on the network while you're uploading/downloading.

defcon.klaxon said:

4. Another issue I noticed was that any ancillary data that my laptop was broadcasting on the network would eventually try to broadcast through the radio. . .

Click to expand...

I never even considered that part. A firewall was needed of course but I didn't consider filtering outbound... till now. Excellent point.

I wouldn't try to post an entire program but I would try to edit one. I'll be deploying new PLCs at the same time and bugs are assured. It would be nice to have that option to make small corrections.

Come on Google Fiber, I have a job for you