Red Lion DA30D Losing Network

[Ken Roach]

They can do their *own* Wireshark captures ? THAT IS SO COOL.

I know that OpenWRT has tshark built in and can report to CloudShark. I wonder what OS they're running under the hood on Crimson 3.1 ?

 

[OkiePC]

They can do their *own* Wireshark captures ? THAT IS SO COOL.

I know that OpenWRT has tshark built in and can report to CloudShark. I wonder what OS they're running under the hood on Crimson 3.1 ?

I don't know what the new hardware OS is, but the files it creates are *.pcap that can be opened directly in Wireshark. I have a trace running that I intend to leave enabled for as long as it takes, but I am not 100% sure it will run indefinitely and create one gigantic trace file, if it discards the oldest data to limit the file size, or if it will stop itself at some point.

The instructions in the technote say I can "Allow the capture to run as long as needed." There must be some limit to this, but like most things Red Lion, those details are not written down in black and white publicly.

 

[kdog]

Anybody ever resolve the dropout issues? We have a DAD30 and experiencing the same random dropout issues. Sometimes it takes weeks or sometimes just a couple of days. A power reboot of the DAD30 always resolves it. Our former engineer spent quite a bit of time with Red Lion Support to try and resolve it and I think they reduced the frequency of the dropouts but never fully resolved.

What is everybody doing for work arounds? Is there an easy way to auto reboot when losing connection?

Kevin

 

[OkiePC]

I have not used the Flex controllers yet or Crimson 3.2, but...

I was recently having issues with a CR3000 (that ended up being mechanical...long story) and it would hang up for long stretches and then recover. One of the many steps Red Lion asked me to try was setting some options in the PLC drivers (Micrologix and SLC) that he said are fairly recent additions.

On the SLC (using the DF1 Master Driver) they have added a Transaction ID type with two settings: Short and Normal.

On the Micrologix driver (Using the DF Master via PCCC/EIP) they have added a "Reconnect on Error" option.

I have no idea if those settings apply to your case, but they might be worth investigating.

 

[ASF]

I don't have anything useful to add insomuch as helping to solve the problem, but I've seen the same behaviour on two DA10 gateways doing Modbus RTU <> Ethernet/IP, installed about a year ago. I know of at least twice since then that they've locked up and refused to talk to the PLC. I could still ping them, and re-downloading the program (which forces a reboot) fixed it. At least one of those two times, both units failed within an hour of each other, after running for several weeks uninterrupted.

 

[jamshidzade]

We have the same issue precisely as WoodyBM explained, we have two DSPLE000 and the device drop off connection with no reason and the only way to comeback is power off unit

Please let me know if you find any solution

 

[Anthony PLC]

DSPLE000 Red Lion drop outs

We have the same issue precisely as WoodyBM explained, we have two DSPLE000 and the device drop off connection with no reason and the only way to comeback is power off unit

Please let me know if you find any solution

Hi all,

I'm facing a similar issue with the Red Lion DSPLE000 protocol converter. I have 4 x Mitsubishi Q-series PLC's that communicate with a CompactLogix L36ER PLC. Communications between the Mitsubishi and Compactlogix seem to drop off randomly. I wired up a switch to reset/power cycle the Red Lion converter which seemed to help in the interim. I contacted Red Lion support and was asked to update the database from an L5K to the newer L5K Enhanced Driver. But that too doesn't seem to help. I'm trying to look at other options but no luck. Has anyone figured this out ?

Thanks..

 

[Anthony PLC]

Hi Jamshidzade,

Not sure if you've had any luck fixing up the problem with DSPLE000 but I did the following to reduce the number of comms drop outs :
(a)L5K Enhanced driver, for Allen Bradley PLC's : Select an L5K Enhanced driver in Crimson 3.XX, instead of an L5K Driver, if you're using an Allen Bradley PLC while preparing the database. The L5K database is unable to restore/revive comms after drop outs in the DSPLE000 converter. I've observed significant changes in the response of the converter unit.

(b) Analyse network traffic of DSPLE000 : You can analyse traffic entering and leaving the DSPLE's data port if it is directly connected to a port on a managed switch. For that you must mirror that port on the managed switch and use Wireshark to take packet captures for around 10-15 minutes max to analyse traffic on the protocol converter. This would also help you corelate network issues or network congestion which may cause the DSPLE000 to sow down its response and eventually drop out. I tried this as well and it helped me immensely.

(c) Database analysis : Check the cd3 database you've created in Crimson 3.XX. Check for doubled up tags, addresses, incorrect mapping. Ensure that the tags you're mapping data to / from are present in the respective PLC's tag lists. One of the problems I faced was tags which were included in the cd3 database but weren't present on the AB PLC which caused comms to drop out. It was an accidental discovery but deleting such references also helped me in this regard.

(d) Watch Window : Create a Comms set of tags by using the GETDEVICEONLINE() function in Crimson 3.XX It is available under the SYSTEM tags group on the bottom right hand corner of Crimson 3.XX. Observe tags in real time using a Watch Window in Crimson. If values momentarily toggle between "ON" - " OFF " or "any numeral value" to "n/a" then it indicates a drop out.

I tried these three methods at once and they helped me sort out this issue so far. Hope this gives you some direction to start with...

 

[Anthony PLC]

DSPLE000 converter issues

We have the same issue precisely as WoodyBM explained, we have two DSPLE000 and the device drop off connection with no reason and the only way to comeback is power off unit

Please let me know if you find any solution

Hi Jamshidzade,

Not sure if you've had any luck fixing up the problem with DSPLE000 but I did the following to reduce the number of comms drop outs :
(a)L5K Enhanced driver, for Allen Bradley PLC's : Select an L5K Enhanced driver in Crimson 3.XX, instead of an L5K Driver, if you're using an Allen Bradley PLC while preparing the database. The L5K database is unable to restore/revive comms after drop outs in the DSPLE000 converter. I've observed significant changes in the response of the converter unit.

(b) Analyse network traffic of DSPLE000 : You can analyse traffic entering and leaving the DSPLE's data port if it is directly connected to a port on a managed switch. For that you must mirror that port on the managed switch and use Wireshark to take packet captures for around 10-15 minutes max to analyse traffic on the protocol converter. This would also help you corelate network issues or network congestion which may cause the DSPLE000 to sow down its response and eventually drop out. I tried this as well and it helped me immensely.

(c) Database analysis : Check the cd3 database you've created in Crimson 3.XX. Check for doubled up tags, addresses, incorrect mapping. Ensure that the tags you're mapping data to / from are present in the respective PLC's tag lists. One of the problems I faced was tags which were included in the cd3 database but weren't present on the AB PLC which caused comms to drop out. It was an accidental discovery but deleting such references also helped me in this regard.

(d) Watch Window : Create a Comms set of tags by using the GETDEVICEONLINE() function in Crimson 3.XX It is available under the SYSTEM tags group on the bottom right hand corner of Crimson 3.XX. Observe tags in real time using a Watch Window in Crimson. If values momentarily toggle between "ON" - " OFF " or "any numeral value" to "n/a" then it indicates a drop out.

I tried these three methods at once and they helped me sort out this issue so far. Hope this gives you some direction to start with...

 

[Drikus Boshoff]

There have been multiple revisions since that build and a lot of fixes with very little documentation about the details of what they fixed.

I would recommend updating to the latest build 3116.000 and also add a button on the HMI somewhere not on a main page that will reboot the controller.

I have not used the DA300, but have had connectivity issues with 2 of my CR3000 HMIs. I can clear up the communications with a reboot and can do it remotely by assigned a button the function CommitAndReset(). I think this has happened even after updating them to the latest build.

Also, I always have flag tags for each device the unit is set up to communicate with that monitor IsDeviceOnline(x) where x is the device number or name. With Modbus, you have to enable the Ping Holding Register for this to work. By default the Ping Holding Register is enabled and set to holding register 1. I always add an alarm (Active Off) to that tag and most of my Crimson apps have Mail Manager set up to notify the operator when selected alarms occur, so rather than having to constantly check on it, it can reach out to you or at least show an alarm on your banner or alarm lists to tell you the comms are broken.

Of course if the Ethernet port of the hardware is completely hosed up when this happens, it can't send messages either. In my cases, it appears to just lose comms to the PLC (A/B). I am assuming that the remote view of the built in web server still works...in my CR3000 that have had issues, that part still functions fine.

I have had log files stop recording due to problems with SD cards. I have also had to tweak some settings in the Web Server for Crimson 3.1 in order to get it to play well with VPN routers and slow internet connections and render correctly in Chrome. I ended up turning compression off for best results (Web Server > Advanced tab > Compression section > Compress Reply: Never)

I know this is a old post - but maybe this can help someone. I have been struggling with Red Lion CR3000 series HMI's - We have quite a few installed. The devices are connected to Controllogix 5000(L5k file) . I have experience different failures( might be due to firmware upgrades): Runtime failure, database corrupted, rebooting, ethernet comms completely fail - cant ping, can still ping units but tags not updated on display - the list goes on.

I tried multiple suggestions but nothing worked, eventually i found a solution - added a ethernet/ip slave protocol to the CR3000 and setup a generic ethernet module in the Controllogix to communicate with the CR3000. The connection is updated at a RPI of 10ms.

No more ethernet communication failures.