Beware of Digi

[BAJ]

Sorry, have to vent here.

I've used a number of Digi products over the years with success. We recently installed a number of the Digi ONE IAP for a customer to interface their Modbus TCP power meters to ControlLogix. I found the setup to be very easy and the PLC MSG logic quite simple, they just worked. All these systems had one power meter, very simple.

We just installed another system with multiple power meters and a handful of Modbus 485 transmitters. During checkout we found a bug in their firmware, if you try to send a MSG to a Modbus device that is not present on the network (like someone disconnects local power for maintenance), it locks up the Digi ONE IAP until the device returns and is able to communicate. None of the other devices on the network can communicate, all MSG blocks to the Digi will timeout. Even their debug logging mode (telnet, if I remember correctly) freezes up.

So Digi has made the moronic decision that this type of problem is not a support problem. They refuse to fix (or even investigate) without a purchase order from us to pay them to do so. I spent time making it simple for them (admittedly our system was somewhat complex) by setting up a test system with just the PLC, the Digi, and one Modbus device and was able to reproduced the problem. They sat on that info for a month, but just replied they still refuse to look into the problem. So what they are telling me is that even though this is obviously a firmware problem in their product, which I have made very simple for them to test, they want us to pay them to fix their own faulty product.

Make your own decision, but consider yourself warned. I'm done with Digi. I'll be using products from other suppliers.

 

[Firejo]

Assuming the Modbus devices are Modbus Slaves, this will do the job (and their customer service is top notch).
https://www.spectrumcontrols.com/products/universal-gateway/

 

[dcooper33]

Sorry, have to vent here.

I've used a number of Digi products over the years with success. We recently installed a number of the Digi ONE IAP for a customer to interface their Modbus TCP power meters to ControlLogix. I found the setup to be very easy and the PLC MSG logic quite simple, they just worked. All these systems had one power meter, very simple.

We just installed another system with multiple power meters and a handful of Modbus 485 transmitters. During checkout we found a bug in their firmware, if you try to send a MSG to a Modbus device that is not present on the network (like someone disconnects local power for maintenance), it locks up the Digi ONE IAP until the device returns and is able to communicate. None of the other devices on the network can communicate, all MSG blocks to the Digi will timeout. Even their debug logging mode (telnet, if I remember correctly) freezes up.

So Digi has made the moronic decision that this type of problem is not a support problem. They refuse to fix (or even investigate) without a purchase order from us to pay them to do so. I spent time making it simple for them (admittedly our system was somewhat complex) by setting up a test system with just the PLC, the Digi, and one Modbus device and was able to reproduced the problem. They sat on that info for a month, but just replied they still refuse to look into the problem. So what they are telling me is that even though this is obviously a firmware problem in their product, which I have made very simple for them to test, they want us to pay them to fix their own faulty product.

Make your own decision, but consider yourself warned. I'm done with Digi. I'll be using products from other suppliers.

That's insane that they would not be eager to fix such a glaring vulnerability in their firmware. Did you get the brush-off from multiple folks in the Digi organization? I'm hoping that it was just a case of you and/or the support tech having a bad day and the rep trying to avoid responsibility. If this really is their organization's position, I don't blame you for not wanting to use their products, market share be damned. Any communication hardware in the days of Industry 4.0 that can't handle a single device disconnect is not fit for industrial use, IMO.

 

[BAJ]

Multiple times over ~2 months of working on it on and off. Same tech support rep though I believe. Here is the last reply I got.

Brad,

engineering has rejected you request and will not look into your issue. As I stated when the case was first opened the product is as is. I will be closing your case.

Respectfully,

I'm extra disgusted this is coming from a MN company.

 

[mp91]

That's insane. They should be THANKING you for finding such a glaring failure in their product.

 

[BAJ]

Assuming the Modbus devices are Modbus Slaves, this will do the job (and their customer service is top notch).
https://www.spectrumcontrols.com/products/universal-gateway/

Thanks Firejo. I will certainly check this out. I have been very satisfied with previous Spectrum products, up to but not including the 1734sc-IF4U. I'll take the blame for not completely reading and understanding the specs on it before we bought it, but it sure was a let-down given what I'd come to expect from them.

 

[BAJ]

That's insane. They should be THANKING you for finding such a glaring failure in their product.

I couldn't agree more. Especially since I spent the time to prove the issue was reproduceable with one Modbus device.

I can't fathom the lack of logic for this as a business model either. My only guess is some "business genius" decided tech support should be treated as a self-funding cost center. Bad decisions like this generally don't last long, either they will figure it out quick and change it or go out of business after losing too many customers.

 

[danw]

no time-out setting on the master/client side?

What is the DigiOne function? Why do you send it a message rather than sending the message directly to the Modbus server/slave? Is the DigiOne a protocol converter? If so, then it would be Modbus master/client on the Modbus side.

The failure of a server/slave on a Modbus RTU multidrop or TCP network slowing communication is an acknowledged shortcoming of Modbus.

Every Modbus master/client that I am aware of has a time-out setting. The time-out setting is used to release the master/client from waiting for a server/slave reply that might not be forthcoming (because the server/slave is turned off or is out of commission). When the timer times out the master/client is allowed to progress onto the next task, presumably polling the next slave in the sequence.

Is there no time-out function on the master/client side?

 

[harryting]

"Is there no time-out function on the master/client side?"

Seems to be what the OP is saying. I guess you can argue that's it's lacking a feature rather a bug.

 

[BAJ]

What is the DigiOne function? Why do you send it a message rather than sending the message directly to the Modbus server/slave? Is the DigiOne a protocol converter? If so, then it would be Modbus master/client on the Modbus side.

The failure of a server/slave on a Modbus RTU multidrop or TCP network slowing communication is an acknowledged shortcoming of Modbus.

Every Modbus master/client that I am aware of has a time-out setting. The time-out setting is used to release the master/client from waiting for a server/slave reply that might not be forthcoming (because the server/slave is turned off or is out of commission). When the timer times out the master/client is allowed to progress onto the next task, presumably polling the next slave in the sequence.

Is there no time-out function on the master/client side?

Yes, it's an Ethernet/IP to Modbus RTU/TCP protocol converter. Works great with one device, or in our most recent case, 10 devices - do long as all 10 devices remain active on the system. In the real world components can go offline for maintenance, or perhaps are part of portable systems. The Digi One IAP can't handle that.


There are 4 timeout settings in the Digi One IAP:

Setting the timeouts
Setting a valid combination of timeouts requires the correct relationship between the four key timeouts
you need to manage. The best defaults to start will be:
• The master application’s slave timeout: 3 seconds
• The Digi One IAP’s message timeout: default of 2.5 seconds
• The Digi One IAP’s slave timeout: default of 1 second
• The Digi One IAP’s character timeout: 50 milliseconds

The problem is something on the slave-side (at least) doesn't work. I left one device powered-off and went to lunch, and an hour later the Digi was still locked-up -- 9 healthy devices with no comms. After I restored power to the 10th slave device the entire system came back up working, all 10 devices communicating. This is a firmware bug.

 

[danw]

That's a bug. DigiOne is not paying attention to the time-outs.


Anyone want to bet that Digi now 'outsources' its coding/programming?

 

[harryting]

That's a bug. DigiOne is not paying attention to the time-outs.

Agreed.

 

[V0N_hydro]

Hi Baj,


I experienced something similar. my setup had one digi one IAP, three control logix CPUs, and 6 TCP/IP modbus slaves.


I was amazed that it worked (and continues to work), but I did notice if one of the slaves was not responding then the digi one IAP essentially rebooted in a loop until all the slaves were on-line again.


I never asked them about it since if one of my slaves isn't working probably the whole plant is down, and they are read only for trend data only, but definitely a pretty glaring issue with the product.


the digi one IAP is great bang for the buck and extremely versatile.

 

[BAJ]

Hi Baj,

I experienced something similar. my setup had one digi one IAP, three control logix CPUs, and 6 TCP/IP modbus slaves.

I was amazed that it worked (and continues to work), but I did notice if one of the slaves was not responding then the digi one IAP essentially rebooted in a loop until all the slaves were on-line again.

I never asked them about it since if one of my slaves isn't working probably the whole plant is down, and they are read only for trend data only, but definitely a pretty glaring issue with the product.

the digi one IAP is great bang for the buck and extremely versatile.

I agree, their products have been good in the past, and the Digi One IAP works well if everything is perfect, but this bug is a pretty glaring flaw and their refusal to investigate/correct is something I won't tolerate, not for our company and certainly not for my customers. As an integrator this makes me look bad too when I'm the one who selected/installed it.

I'm going to try the Spectrum unit recommended by Firejo above on our next installation, the cost is comparable and for $200 more you can interface to Siemens also.
https://www.spectrumcontrols.com/pro...ersal-gateway/

 

[VAN]

Can you put in an older firmware rev. that you know was working before?