Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: SceneryDriver on February 06, 2026, 10:38:44 PM
-
All,
I have a BX-DM1E-10ED13-D with two expansion modules: BX-08TD1 and BX-08AD-1. PLC is running fine, but I found out today that I can no longer connect to it over Ethernet. It was programmed in Do-More Designer 2.11.1 in December, and has been running fine.
DMD can no longer connect to it, and can't even see it. NetEdit3 can sort of see it, but it displays an IP address of 0.0.0.0. Last time I connected, it had the expected IP address of 10.101.50.14. I cannot alter the IP address in NetEdit; I get an error. I cannot ping the PLC at its expected address.
Weirdly, the PLC is still successfully communicating with two CM5 touchscreens, and everything is still running. I've tried a power cycle, as well as putting the PLC in STOP, switching to RUN, and back to TERM with no effect.
Do I need to use the onboard DIP switches to go through clearing the Ethernet settings, and give the PLC its settings again? Complicating this is the fact that I'm supporting this system from several states away, and I'd rather not bork an otherwise operating system. I can have an onsite tech wipe the Ethernet settings if that'll help.
I've never seen this behavior from a BRX. What might cause the PLC to (sort of) dump its network settings, while still talking to two CM5 touchscreens over Ethernet?
Sincerely,
SceneryDriver
-
A bit more info: I've tried IPConfig over the VPN connection, and IPConfig can't find the PLC.
SceneryDriver
-
Is it using DHCP or did you assign it a static IP address?
-
The PLC was assigned a static IP address and subnet mask.
SceneryDriver
-
Does your VPN network configuration supporting pinging the remote devices?
Can you ping the PLC via command line?
Can you ping the HMI panels?
Can you remotely connect to the HMI panels using their configuration software (assuming you could do this before this 0.0.0.0 issue showed up)?
-
Does your VPN network configuration supporting pinging the remote devices?
Can you ping the PLC via command line?
Can you ping the HMI panels?
Can you remotely connect to the HMI panels using their configuration software (assuming you could do this before this 0.0.0.0 issue showed up)?
The VPN does support pinging devices on the remote network.
I cannot ping the PLC via the command line.
I can successfully ping the HMI panels.
I can remotely connect to the CM5 panels with the C-more touchscreen software.
-
Can someone remotely connect to the PLC (Ethernet, USB, Serial) and look at the SysInfo page and report what that page reports for the IP Configuration parameters on the General Information tab?
-
Can someone remotely connect to the PLC (Ethernet, USB, Serial) and look at the SysInfo page and report what that page reports for the IP Configuration parameters on the General Information tab?
I tried that already via Ethernet (to the PLC) on a laptop running Chrome Remote Desktop (via wifi) and DMD. I was unable to connect to the PLC or ping it when connected locally with the laptop and Chrome Remote Desktop / DMD. I did make sure to give the laptop's Ethernet port a static IP address in the correct subnet as it was connected directly to the PLC with only a cable (no DHCP server anywhere in the mix).
I don't have a USB POM installed in the unit, and they don't have the cable to attempt a serial connection.
SceneryDriver
-
0.0.0.0 is definitely wrong - trying to figure out the extent of the failure.
Once someone remotely is able to connect to it, the System Log may have some clues as to what happened/when.
ipconfig uses directed broadcasts - if that is not working now, not sure if "clearing" the IP configuration via dipswitches will make it work over VPN, but you can try. Hopefully that will work - and then get a copy of the System Log.
-
0.0.0.0 is definitely wrong - trying to figure out the extent of the failure.
Once someone remotely is able to connect to it, the System Log may have some clues as to what happened/when.
ipconfig uses directed broadcasts - if that is not working now, not sure if "clearing" the IP configuration via dipswitches will make it work over VPN, but you can try. Hopefully that will work - and then get a copy of the System Log.
I have a tech onsite who can do a direct-connect laptop running DMD, so I'll be happy if we can get it back that way at least . I'll walk them through clearing the IP config via the DIP switches this afternoon and report back.
SceneryDriver
-
An update:
My onsite tech was able to connect the laptop running DMD directly to the PLC. I used the IP Config utility to successfully (or so I thought) set the desired IP address and subnet mask. I was then able to ping the PLC at:
10.101.50.14
255.255.0.0
NetEdit3 and DMD could now detect the PLC however, it was still displaying 0.0.0.0 PLC IP Address is invalid in DMD. Similar in NetEdit3.
As seen in the attached screen grabs, I tried to update the PLC in DMD to the above IP address, but DMD wouldn't let me as it said there was an IP address conflict with a device at 10.101.50.14; I tried to set it to 10.101.50.51 (I knew that was an unused address). DMD threw an error when I tried to update the IP address.
I then had my tech do the DIP switch hardware wipe of the network settings. The reset seems to have worked, in that I can no longer ping the PLC at 10.101.50.14, but I can also no longer find it in IP Config, NetEdit3, or DMD. I cannot ping the PLC at all, and it's no longer communicating with the touchscreens.
Feels like time to throw in the towel and start the RMA process. Do I send the PLC back to AutomationDirect, or to Host for forensics? Happy to do either but I'd really like to know what happened. I do have a spare PLC on the shelf, so I can get a new unit out to the client while waiting for a return/replacement.
SceneryDriver
-
1. Have remote person set the IP address.
2. Have the remote person power cycle the PLC
3. Have the remote person verify the IP address
4. Use the Blink Error Light on the Select Link dialog to get a time frame for the VPN overhead. The turnaround time shows up in the Enabled column.
5. Hit the Edit Link button on the Select Link dialog, select Port tab, Advanced Settings button, and make sure your Timeout is 2x of that turn-around time value for your Communication Link (or more, e.g. 40ms turnaround, make it 80ms or 100ms)
6. You just connect to the PLC - do NOT try to change the IP address using the IP address you are about to change
-
1. Have remote person set the IP address.
2. Have the remote person power cycle the PLC
3. Have the remote person verify the IP address
4. Use the Blink Error Light on the Select Link dialog to get a time frame for the VPN overhead. The turnaround time shows up in the Enabled column.
5. Hit the Edit Link button on the Select Link dialog, select Port tab, Advanced Settings button, and make sure your Timeout is 2x of that turn-around time value for your Communication Link (or more, e.g. 40ms turnaround, make it 80ms or 100ms)
6. You just connect to the PLC - do NOT try to change the IP address using the IP address you are about to change
We've basically done exactly what you describe. We used IP Config on a local PC connected directly to the PLC to set the IP address. It would respond to pings and the expected IP address successfully.
However, there was no way to connect to the PLC in DMD. The PLC wouldn't respond when I tried to edit the link to the IP address set via IP Config, and DMD saw a new PLC at 0.0.0.0 Trying to connect to it and give it any IP address was unsuccessful, with the error message posted above.
After the hardware reset of the network settings, I can no longer set the IP address in IP Config, or any other way. It doesn't even show up as a new unconfigured unit that needs its network settings.
It's still running its program, just not communicating with the outside world.
Question: If I send out the spare unit I have on the shelf, I'd like pre-load the program and pre-configure the netowrk settings. Will I have issue loading the program since the program is expecting an analog module to be installed, and my replacement won't have one (until it's all put together onsite)?
SceneryDriver
-
However, there was no way to connect to the PLC in DMD
Is that locally or remotely or both? Being able to connect locally tells us that the IP setup is valid and working locally.
-
However, there was no way to connect to the PLC in DMD
Is that locally or remotely or both? Being able to connect locally tells us that the IP setup is valid and working locally.
We did everything locally, using a laptop with a direct connection to the PLC through Ethernet, and a remote connection via Chrome remote Desktop over wifi. IP config worked, but kinda seemed not to - DMD couldn't see the PLC as anything but 0.0.0.0 even after giving the PLC it's IP address with IP Config.
SceneryDriver
-
Very strange. Do you happen to have a USB or Serial POM you could try (is POM slot open)?
-
Very strange. Do you happen to have a USB or Serial POM you could try (is POM slot open)?
I don't currently - I'd have to order one. The serial port on the unit is not currently used for anything, and according to the project file, it should be set for DoMore protocol, RS232, 115kbaud (all default settings). I can see about trying to recover the thing via its serial port, but not sure I can afford the time for a tech onsite to continue poking at it.
To add to the mix, this is a remote site, and the tech had to get pulled off for another job. I have to work on getting someone out there again. At this point, I really just want to swap the PLC with a spare (with its IP address already properly set) and re-upload the program once it's reinstalled with its analog module.
Should I send the borked PLC back to Host or to AD to try to figure out what happened? I'd really like someone to pull the logs and tell me what went wrong. The whole point of this endeavor was to set up remote access for off-site support. It works really well for the other BRX onsite, but not this one unfortunately.
SceneryDriver
-
Yes, we would like to figure out what's going on. Sent you a PM with the details.
-
Got it. Hopefully we can figure it out. Thank you!!
-
Took a look at your unit. The security config had NetEdit support disabled for the primary port. When I enabled it the unit immediately started responding correctly. I can't be certain that was your specific issue, but I am certain things won't work correctly with NetEdit support disabled.
I don't think we have your address to return the unit. The return address was to a UPS store. Please PM me the correct address and we'll get it in the mail.
-
Took a look at your unit. The security config had NetEdit support disabled for the primary port. When I enabled it the unit immediately started responding correctly. I can't be certain that was your specific issue, but I am certain things won't work correctly with NetEdit support disabled.
I don't think we have your address to return the unit. The return address was to a UPS store. Please PM me the correct address and we'll get it in the mail.
BobO,
Thank you for looking at (and fixing) my PLC. I have absolutely no idea how NetEdit support was disabled on the Ethernet port. When I left the unit after commissioning in December, it was working. There's no one at the site who had the software/knowledge to disable that. In fact, I didn't even know that was an option. Very weird. The power quality out there isn't the greatest - could a brownout/fast power cycle caused this issue? I'd guess not, but I thought I'd ask.
I've sent you a DM with my shipping info. I thought I was replying to franji's DMs, but I guess not.
Thanks to you and franji again! Host's support is unmatched!
Sincerely,
SceneryDriver
-
PM's the USPS tracking #
-
BobO,
Thank you for looking at (and fixing) my PLC. I have absolutely no idea how NetEdit support was disabled on the Ethernet port. When I left the unit after commissioning in December, it was working. There's no one at the site who had the software/knowledge to disable that. In fact, I didn't even know that was an option. Very weird. The power quality out there isn't the greatest - could a brownout/fast power cycle caused this issue? I'd guess not, but I thought I'd ask.
I've sent you a DM with my shipping info. I thought I was replying to franji's DMs, but I guess not.
Thanks to you and franji again! Host's support is unmatched!
Sincerely,
SceneryDriver
Since we prompt the user to choose security settings for old projects, we've had a few users inadvertently disable something they needed. As far as we are aware, the settings aren't changing themselves...although I've learned to never say never. If it happens again please let us know.
-
Since we prompt the user to choose security settings for old projects, we've had a few users inadvertently disable something they needed. As far as we are aware, the settings aren't changing themselves...although I've learned to never say never. If it happens again please let us know.
[/quote]
I received the PLC. Thanks!
Is NetEdit enabled/disabled stored as a single bit? Could this have been a bit flip? I'm the only one who touched that program, and it was a new project as of December last year.
I used the hardware DIP switches to wipe out the Network settings and tried to recover the COMs that way. Since it was the NetEdit setting, would using the DIP switches to completely wipe the PLC back to factory defaults and reloading the program have worked? Asking in case I have to talk someone through this in the future.
Thanks,
SceneryDriver
-
I received the PLC. Thanks!
Is NetEdit enabled/disabled stored as a single bit? Could this have been a bit flip? I'm the only one who touched that program, and it was a new project as of December last year.
I used the hardware DIP switches to wipe out the Network settings and tried to recover the COMs that way. Since it was the NetEdit setting, would using the DIP switches to completely wipe the PLC back to factory defaults and reloading the program have worked? Asking in case I have to talk someone through this in the future.
Thanks,
SceneryDriver
I would be very surprised if the flash was corrupted. Everything else seemed fine. The only thing I saw was that NetEdit and legacy support was disabled on the internal port. As I mentioned we do automatically prompt when you open an older project...one where the security settings haven't been set previously. We've had a couple of reports of folks ending up with some stuff disabled. To this point we're thinking they are handling the dialog without fully overstanding what we're asking...but...it's certainly possible that something is busted in the process of migrating the old project.
Yes, using the magic handshake to wipe the memory will restore the comms. The bad setting is still in your project though, so as soon as you write your project NetEdit goes away again. You just need to edit the project offline or before you write it to the PLC. Go to the SysConfig->CPU Configuration and select "Security Settings..." in the middle of the dialog. If memory serves, your project had "Disable Unencrypted Programming" unchecked and both "Disable NetEdit Setup" and "Disable Legacy Protocols" were checked.