client is asking about Red Lion Data Station Plus with Scadapacks

defcon.klaxon

Lifetime Supporting Member
Join Date
Feb 2015
Location
Far NorCal
Posts
616
Hey guys,

One of my clients that I support has asked me whether or not going from a traditional radio system (Teledesign TS4000s) to a wireless ISP solution would be a good idea. The idea is that there is a local wireless ISP that has done something similar for another water district in the area, and they created a VLAN to allow several GE RX3i PLCs to communicate with one another through this VLAN. Apparently they're using Red Lion Data Station Plus devices for security and protocol conversion.

The client in question is running Scadapacks via Modbus; I downloaded Crimson and took a look and it seems that you have to specifically tell the DSP what data is being sent back and forth, it's not just a "switch".

I'm wondering what your experience with the DSP is, whether or not you'd suggest using it and since we're on the topic, is it worth transitioning from a radio system to this? I like to keep things simple; radios are relatively straightforward to understand, you're not relying on an ISP and this sounds like a whole other level of complexity. But, the potential payoff is faster data (which is absurd to me, since their polling time is about one minute for all sites...how fast do you really need to see wells running and tank levels?)
 
The red lion dsp is a great unit for protocol conversion.
However if all you have to do is convert the serial based modbusRTU and convert it to ModbusTCP so you can go over an essentially Ethernet network you.can buy a converter that allows you to poll any address.
In fact even I have cellular modems with that function built in. Microhard modems. And many others do that as well. The microhard also has a firewall on it. But you need a static up and data plan to do that.
I'
F I understand you correct I wouldn't use the dsp unless you. Need to.convert.
 
going from a traditional radio system (Teledesign TS4000s) to a wireless ISP solution would be a good idea.

So you already have a system that is working, and you just want to connect point A to point B with something other than a "Radio System"?

However, if you are looking for a better way of transferring "REAL-TIME" data back and forth. Then I would look into using MQTT as your protocol for delivery.

You can think of MQTT as the wire between any (two points or more), and the overhead is so lightweight that "Cellular VPN" networks can easily handle this protocol without hugh bandwidth charges.

Just an Idea you may want to look into.
 
The red lion dsp is a great unit for protocol conversion.
However if all you have to do is convert the serial based modbusRTU and convert it to ModbusTCP so you can go over an essentially Ethernet network you.can buy a converter that allows you to poll any address.
In fact even I have cellular modems with that function built in. Microhard modems. And many others do that as well. The microhard also has a firewall on it. But you need a static up and data plan to do that.
I'
F I understand you correct I wouldn't use the dsp unless you. Need to.convert.

Interesting thoughts, thanks for the input. Yeah, basically the existing system is ModbusRTU, and the Scadapacks are old enough that they don't have ethernet built in, only RS232 dsubs.

As for the converter from ModbusRTU to TCP, can you link to some you'd recommend?

And yeah, DSP has been suggested because it's known, not necessarily because it's the best solution.
 
So you already have a system that is working, and you just want to connect point A to point B with something other than a "Radio System"?

Exactly.

However, if you are looking for a better way of transferring "REAL-TIME" data back and forth. Then I would look into using MQTT as your protocol for delivery.

You can think of MQTT as the wire between any (two points or more), and the overhead is so lightweight that "Cellular VPN" networks can easily handle this protocol without hugh bandwidth charges.
Sounds interesting; how exactly are you suggesting to implement MQTT? I've done some searching and it looks like you need a data broker for the data, plus you'd need hardware capable of running MQTT...sounds like for a simpler rural water system, a bit complex to implement and maintain but maybe I'm not understanding the way to set this up.
 
Last edited:
I'd recommend a moxa and if also recommend a Digione IAP. The latter being the cheaper solution but both a fully functional.

Back to the red lion though. If you have other things going on on site now or in the future a dsp can solve multiple needs. That's what I am currently doing right now. I have 2 Scadapacks both with Ethernet and serial but I need another serial port as well as data to go between the 2. I could do ModbusTCP master polling in my isagraf program but then I'd also need a convertorĺ such as the digione. And then that still leaves me out in the blue when it comes to the Allen Bradley and Scadapacks talking to eachother. If not for the last part then a digione would probably been my choice
 
Ok, Simple.

Example: (Step One) They already have a system (Can a simple Hmi $299.00) be added into this system?? (If YES, move to step two)

Step Two:
Then you could add a Maple System HMI5043LB(You don't really need to put this screen to use, just let it publish) at $299.00 because it is an "MQTT Edge Gateway", you can setup all of the "Tags" to be published using the MQTT Protocol(This Hmi can be the publisher and the Broker at the same time!).

Step Three:
Then you could get the OPC-MQTT client from open automation for $549.00 this would then allow you to subscribe to all the tags(These will be what even data you are wanting, Levels, pressure, temperature, Amps, Hz, Rpm, Run Times, Etc..)

The OPC-MQTT client can interface with almost any type of scada database. SQL, Access, Excel, Etc..

If I could not convince them that - now is the time to start implementing new technology, I don't know if I would be the one they should be talking with.

As always this is just my opinion. Now should you decide that you want check into this further I really recommend reaching out to Cirrus Link (Mr. Arlen Nipper) he is the co-inventor of the MQTT Protocol, he is very reachable.
 
I would stick with your own point to point radios that are already working perfectly (?) instead of switching to relying on multiple layers of ISP infrastructure you have no control over. There will be radios, switches, routers, firewalls, who knows how many devices in the path between your two devices which are now communicating directly and predictably over a serial link.

The TS4000 are an industrial product designed for low data rates over VHF, UHF, and 900 MHz. The wireless ISP will deploy a consumer or commercial grade of product unless you are paying megabucks and it will be in a different frequency band which may or not run in to interference and path issues. The wireless ISPs equipment will be more sensitive to all manners of wireless issues since it will be designed for much higher data rates.

By all means get the ISP to provide voice or LAN wirelessly to your control panels if that's what you need, but I would be real cautious about migrating your control communications over to an ISP without some specific guarantees about the level of service you can expect and confidence that they can deliver it.

Maybe whatever the data is isn't very important, or the existing system has problems, but it seems ludicrous to switch from an already paid for working system to paying monthly for something infinitely more complicated and therefore more likely to fall over.

I have designed and deployed wireless networks with the cheapest equipment available covering 10-100km areas and so I have had many wireless headaches mostly caused by bad paths and rampant optimism.
 
Ok, Simple.

Example: (Step One) They already have a system (Can a simple Hmi $299.00) be added into this system?? (If YES, move to step two)

Step Two:
Then you could add a Maple System HMI5043LB(You don't really need to put this screen to use, just let it publish) at $299.00 because it is an "MQTT Edge Gateway", you can setup all of the "Tags" to be published using the MQTT Protocol(This Hmi can be the publisher and the Broker at the same time!).

Step Three:
Then you could get the OPC-MQTT client from open automation for $549.00 this would then allow you to subscribe to all the tags(These will be what even data you are wanting, Levels, pressure, temperature, Amps, Hz, Rpm, Run Times, Etc..)

The OPC-MQTT client can interface with almost any type of scada database. SQL, Access, Excel, Etc..

If I could not convince them that - now is the time to start implementing new technology, I don't know if I would be the one they should be talking with.

As always this is just my opinion. Now should you decide that you want check into this further I really recommend reaching out to Cirrus Link (Mr. Arlen Nipper) he is the co-inventor of the MQTT Protocol, he is very reachable.

Thanks for taking the time to explain all that; very interesting possibilities there. Cheers!
 
I would stick with your own point to point radios that are already working perfectly (?) instead of switching to relying on multiple layers of ISP infrastructure you have no control over. There will be radios, switches, routers, firewalls, who knows how many devices in the path between your two devices which are now communicating directly and predictably over a serial link.

The TS4000 are an industrial product designed for low data rates over VHF, UHF, and 900 MHz. The wireless ISP will deploy a consumer or commercial grade of product unless you are paying megabucks and it will be in a different frequency band which may or not run in to interference and path issues. The wireless ISPs equipment will be more sensitive to all manners of wireless issues since it will be designed for much higher data rates.

By all means get the ISP to provide voice or LAN wirelessly to your control panels if that's what you need, but I would be real cautious about migrating your control communications over to an ISP without some specific guarantees about the level of service you can expect and confidence that they can deliver it.

Maybe whatever the data is isn't very important, or the existing system has problems, but it seems ludicrous to switch from an already paid for working system to paying monthly for something infinitely more complicated and therefore more likely to fall over.

I have designed and deployed wireless networks with the cheapest equipment available covering 10-100km areas and so I have had many wireless headaches mostly caused by bad paths and rampant optimism.

That's pretty much how I've been thinking about it; I wanted to ask others and make sure I wasn't being overly conservative but you really highlighted my concerns.

As far as the radios working "perfectly", that's pretty much why this conversation was brought up in the first place. The client has been having comms failure issues which I've been trying to help them diagnose. They're also not really happy about how long the polling time is taking, but when I checked out the code I found that the previous programmer has as many as five or six separate MSTR blocks for each site, which I think is what may be making things run so slowly; he literally will read a block of holding registers, then use another MSTR block to read another holding register that is like five addresses away. It all seems very sloppy and added on as he went, instead of packing data into holding registers and using a single MSTR block. Thus, the client heard about this "real time" solution that another guy is using and wanted to find out about it. What I only recently found out was, the guy who suggested the ISP solution himself doesn't trust it to write, and he only uses it to read data like tank levels and etc.
 
Last edited:

Similar Topics

Hello, We have two stand alone FactoryTalk Site Edition clients running. Recently we've had a problem with FactoryTalk Linx on one of them. After...
Replies
1
Views
68
Hi everyone, I've got some trouble lately with a client and his communication with the server. I'm a beginner, and the project was not orginally...
Replies
0
Views
63
Hello, I'm working on a laptop that needs FactoryTalk Activation Manager installed on it as a host along with a Hyper-V VM client on the same...
Replies
0
Views
79
AssetCentre Client loads correctly on the server, but when going through another machine the client never presents a splash screen; however, it...
Replies
1
Views
122
Hello everyone, I am working in a platform and we installed FTV CLIENT SE V 12 IN ALL THE CLIENTS COMPUTERS, we have 6 clients and only 1 is not...
Replies
0
Views
79
Back
Top Bottom