Just wondering if anyone has used an event driven protocol in Ignition yet? We have a few applications where they make a lot of sense. If you have how was your experience and what protocols did you use?
I have had mixed experiences in the past with them on other software platforms.
Thanks!
What protocols did you use with other platforms?
The only protocol I’m familiar with, if I understand what you’re talking about correctly, is DNP3.
I have used DNP3 in the past, my problem is coming from the water world I haven’t found a lot of equipment that supports DNP3 and doesn’t have super crappy programming software. At least that I know of. If anyone out there knows of one that is decent and doesn’t make you feel like you are back in the 80s while you program it let me know!
I have used some other odd-ball ones that were home grown - those were the very mixed experiences…
Ive done very limited research on something called mqtt. there seems to be very few manufacturers getting into it but alot of people that fool around with microprocessors seem to be playing with it.
Here is one company that makes an industrial gateway that would connect to some plcs and then act as a mqtt server. There are also mqtt python libraries that you could possibly import into ignition to act as a client.
elecsyscorp.com/solutions/in … index.html
we have developed a low power satellite based unit that has 4 digital inputs that will cryout(push) input changes to our ignition gateway over web services. we use those for things like monitoring compressors or tank levels. they are great for that application.
The device looks interesting - i will have to look into MQTT. Looks like it could have some neat applications. I will paint a picture of what I am trying to replace.
I must put it out there that I did not install this… I am trying to make it disappear.
There is a remote site with three alarms - that is it. They are all very critical and staff needs to be notified about them within minutes and it is on a solar site. How it is set up now so they don’t drain their batteries is the following:
There is a PLC/RTU that the wires are wired into and a radio. The best part is there is a relay that when one of the alarms is active it turns on the radio and PLC. The master radio is constantly polling this site so when it is turned on it catches the alarm. Obviously you can see some issues with a set-up like this. When there is no alarm the radio and PLC are off. there are two like this - one leaves the PLC on all the time, but that doesn’t really matter.
The biggest issue is how do you know the solar site is actually working and we will get those alarms when they occur?
They need to poll the site every thirty seconds which requires the radio to respond and transmit and drain the batteries if it were left on all the time.
The obvious solution is just put in another array and batteries but we have physical/political limitations that stop us from doing that.
So that is the beauty I am trying to make go away and event based protocol seems to make a lot of sense in an application like this.
Isn’t Inductive working on a DNP3 driver right now?
[quote=“allenr8”]
Isn’t Inductive working on a DNP3 driver right now?[/quote]
Yep, we are. But I’m not sure it would help in this situation. DNP3 slaves can send unsolicited messages, but the assumption is that the TCP connection is maintained at all times.
[quote=“allenr8”]The device looks interesting - i will have to look into MQTT. Looks like it could have some neat applications. I will paint a picture of what I am trying to replace.
I must put it out there that I did not install this… I am trying to make it disappear.
There is a remote site with three alarms - that is it. They are all very critical and staff needs to be notified about them within minutes and it is on a solar site. How it is set up now so they don’t drain their batteries is the following:
There is a PLC/RTU that the wires are wired into and a radio. The best part is there is a relay that when one of the alarms is active it turns on the radio and PLC. The master radio is constantly polling this site so when it is turned on it catches the alarm. Obviously you can see some issues with a set-up like this. When there is no alarm the radio and PLC are off. there are two like this - one leaves the PLC on all the time, but that doesn’t really matter.
The biggest issue is how do you know the solar site is actually working and we will get those alarms when they occur?
They need to poll the site every thirty seconds which requires the radio to respond and transmit and drain the batteries if it were left on all the time.
The obvious solution is just put in another array and batteries but we have physical/political limitations that stop us from doing that.
So that is the beauty I am trying to make go away and event based protocol seems to make a lot of sense in an application like this.
Isn’t Inductive working on a DNP3 driver right now?[/quote]
our satellite unit would be perfect for your application, but it would require a monthly fee. It is a package that includes satellite, solar panel, and battery, about 1.5’ x 1.5’. it has a very small solar panel and battery. the battery is like a 4 amp hour battery and it would power it for months with no solar panel. It also does a check in every 4 hours to let our ignition server know that the battery voltage is good. If it doesnt check in, we have scripts that detect that and send us alarms.
They also make cellular dialout devices that will call or text directly, but that wouldnt integrate into ignition unless they have a modbus interface or something that you could poll independently.
Hi diat,
Any link for this device in pm ?
Thanks
So did you write your own protocol for that device? Is the satellite unit similar to what hightide offers? I wouldn’t mind taking a look at it.