Recent Posts

41

Do-more CPUs and Do-more Designer Software / Decreased RPI time for EtherNet/IP Scanner

« Last post by plcnut on August 17, 2026, 09:38:12 PM »

Hello gentlemen!
Long-time no-see.

I was wondering if there is any way to increase the polling time for EtherNet/IP devices in the scanner.
I am specifically using the Murr 54631 Remote IO blocks which are capable of 1ms on the network, but I am limited in the BRX to 10ms RPI.

I would like to take care of packet loading myself and get better performance from my RIO. I can turn down the polling speed for my drives and run my IO faster.
Thanks for your consideration!

42

Do-more CPUs and Do-more Designer Software / Re: Seemingly random hardware watchdog timeouts

« Last post by ah23 on August 17, 2026, 04:25:55 PM »

Historically, hardware watchdog problems have been noise related. The one thing that stands out to me is the use of the BX-16TRZ relay modules; these versions are simple dry contacts with no onboard noise suppression like we us on the 'regular' BX-16TR module.

You might try adding MOVs to the load side of the relay wiring (not the module side) to see if that has some good effect.

This is an interesting path I hadn't considered, when considering noise, I was mostly thinking about the EMI output from VFD's... Would you suggest installing varistors on all of the contactors? or would switching to the TR models potentially have a similar effect/potential benefit? (thinking about cost/time required) Relatively speaking the TR models, I think they would end up being less in the long run. One of the main things these are driving are small 120v fuji contactors.

In theory would an interposing relay potentially also have a similar effect of isolating the output from noise if it were a 24vdc coil running a 120vac relay to have an isolated power source from the PLC's output relays?

The TRZ's were the selection of the initial electrician that deployed the first small system and I've followed suit on all of my changes/upgrades/updates so I never really dived into the exact reason why that was selected, it was a few bucks more than the "base" model and without suppression that to my IT minded brain is "more simple = less likely to break" so I hadn't dived deeper.

Thanks both of you for your insights, it's greatly appreciated!

43

Do-more CPUs and Do-more Designer Software / Re: Seemingly random hardware watchdog timeouts

« Last post by MikeS on August 17, 2026, 01:33:27 PM »

Historically, hardware watchdog problems have been noise related. The one thing that stands out to me is the use of the BX-16TRZ relay modules; these versions are simple dry contacts with no onboard noise suppression like we us on the 'regular' BX-16TR module.

You might try adding MOVs to the load side of the relay wiring (not the module side) to see if that has some good effect.

44

Do-more CPUs and Do-more Designer Software / Re: Seemingly random hardware watchdog timeouts

« Last post by BobO on August 17, 2026, 12:44:43 PM »

Hardware watchdogs should never happen due to programming. In most cases, it's noise. Rarely, it's an instruction bug.

45

Do-more CPUs and Do-more Designer Software / Re: H2-DM1E Communication Issue

« Last post by BobO on August 17, 2026, 10:02:47 AM »

My facility has a DO-More H2-DM1E controlling 6 GS2 and GS3 VFDs over ethernet over unmanaged switches and GS-EDRV100s.  The switches are SE-SW8U, 8 port automation direct switches that are linked together with an ethernet jumper. The DO-More is also linked with ethernet to 3 C-Mores around the plant over the same unmanaged switches. 

Every two or three months the DO-More will stop being able to control the VFDs and the GS-EDRV100s will stop showing good communication.  The PLC will still communicate with the C-Mores.  But the VFDs will not respond to commands from the PLC.  To get the VFDs back online we have been power cycling the PLC.  This has been going on for over 4 years.

The errors on the CPU are:

Network stack resource allocation failed - $CommStackOverrn (ST146)
One or more user network devices was forcibly purged to free network resources -  $QueuesFlushed (ST145)


Any ideas what could be the root cause?

At the simplest, that error means that the PLC has consumed all of its packet buffers and has done some garbage collection in attempt to recover them. As to what might be causing that, there are many possibilties. We have some advanced diagnostics in the PLC that can help determine the cause. We are happy to guide you through that if you want to contact us at the support email.

46

Do-more CPUs and Do-more Designer Software / Re: Seemingly random hardware watchdog timeouts

« Last post by ah23 on August 17, 2026, 09:42:56 AM »

it doesn't provide any descriptive data to me

Yes, the default tab in the SysInfo dialog does not provide the information in the System Log.  Please select the Event Log tab in the SysInfo dialog and post that here.

That provides a log of things that went on in your system, including all the watchdog timeouts.  Hence, you do not have to wait for it to happen again, since it is a historical log.

Sorry for the delayed response here, adding to the inconsistency making it harder to track, it seems to come in spurts. Thinking of the obvious "What are you doing differently when this occurs?" To my knowledge... Nothing... That's the rub it seems. it'll go a week without a spat then it will do it day over day.
Wednesday August 12th was an actual power cycle, we had a power outage from our service provider, which is exceedingly rare to see happen. My first thought would go to "Does this occur after every full power cycle?" No... unfortunately I believe it can go a week or two of being online and start doing it, case in point, I haven't seen once since my initial post and now have 2 on record and almost expect to see another in the next day or two.
Friday August 14th they would have been wrapping up for the day
Saturday August 15th it was running unattended and the boss was standing in the plant, I have cameras I looked back on, and I saw it disconnect all the relays, then reconnect them as it powered back on, which are the visual symptoms I see with it. I have a stack light within view so that plant status can be visually recorded and I can watch it go dark, then go back solid after a quick flash of it rebooting.

Any further thoughts would be great, but I am fully aware that with the inconsistency it may just be a replace 1 I/O expander at a time, just costly and timely. It's possible I have a gremlin in my programming, but I wouldn't expect to see a hardware watchdog for programming... but maybe?

Thanks for your assistance!

47

Do-more CPUs and Do-more Designer Software / H2-DM1E Communication Issue

« Last post by Saturn_Europa1 on August 17, 2026, 03:30:34 AM »

My facility has a DO-More H2-DM1E controlling 6 GS2 and GS3 VFDs over ethernet over unmanaged switches and GS-EDRV100s.  The switches are SE-SW8U, 8 port automation direct switches that are linked together with an ethernet jumper. The DO-More is also linked with ethernet to 3 C-Mores around the plant over the same unmanaged switches. 

Every two or three months the DO-More will stop being able to control the VFDs and the GS-EDRV100s will stop showing good communication.  The PLC will still communicate with the C-Mores.  But the VFDs will not respond to commands from the PLC.  To get the VFDs back online we have been power cycling the PLC.  This has been going on for over 4 years.

The errors on the CPU are:

Network stack resource allocation failed - $CommStackOverrn (ST146)
One or more user network devices was forcibly purged to free network resources -  $QueuesFlushed (ST145)


Any ideas what could be the root cause?

 

48

General Discussion / Re: Feature Request, Trend View Panes Enlargement

« Last post by franji1 on August 12, 2026, 10:58:12 AM »

Thanks for the response. Just to clarify, and using your terminology, I would like to see a "Arrange Panes" feature for trendviews (including when in history mode) to "minimize, tile vertically or horizontally, cascade, activate," . Thanks!
-Barry

Doh!  Sorry.  Interesting idea.  These are splitter windows, but some of the MDI arrangement can be done (e.g. I/O System View does some interesting stuff with its two splitter widows, "tiling" horizontally vs. vertically).

49

General Discussion / Re: Feature Request, Trend View Panes Enlargement

« Last post by Barnic on August 12, 2026, 10:34:54 AM »

Thanks for the response. Just to clarify, and using your terminology, I would like to see a "Arrange Panes" feature for trendviews (including when in history mode) to "minimize, tile vertically or horizontally, cascade, activate," . Thanks!
-Barry

50

General Discussion / Re: Feature Request, Trend View Panes Enlargement

« Last post by franji1 on August 11, 2026, 05:36:03 PM »

Designer 2.11 has a new Arrange Windows feature under the Windows menu.

It will let you minimize, tile vertically or horizontally, cascade, activate, whatever, each of the main MDI windows.  I recommend maximizing Designer app before doing any MDI window arranging.

We do want to allow "tear off" Trend Views some day - we agree that's a good idea!