Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Bolt on July 06, 2021, 12:30:06 AM
-
I have a new BX-DM1E-18ED23. I have it mounted to a panel and wired to terminal blocks, with ZipLink pigtails.
I cannot get my outputs to enable, either through Force, Ladder Logic, etc. DmD shows the output to be on, but no LED on the BRX illuminates, nor can I measure voltage/continuity at the terminal blocks.
I've tried powering the Y1C and Y2C with the on-board 300mA PS, and with an external PS, (but it should illuminate the LED's even with no power to the C terminals).
I've swapped the CPU into a known working panel's ZipLinks (again, this shouldn't affect the Yn LED's from working anyways).
I have not configured any HSO's or TDO's.
I do not have an LED on Y1C, indicating an output current fault.
I have no I/O Errors.
I have no additional I/O modules, only a serial POM.
I have tried to Re-initialize the I/O.
The Inputs all work as expected.
Please advise.
-
CPU switch in RUN/TERM position?
-
Yep, it's in RUN mode, and processing inputs and communications properly.
-
Any chance you have all your outputs configured to a High Speed Output Axis or other High Speed resource? Driving the Image Register state of Y0 means nothing when configured as a High Speed Output like in an Axis, you cannot control the physical discrete output from Ladder Logic. The LEDs would only flicker if you had an Axis instruction running (or some other enabling high speed resource).
If you run Program Check, you should see warning W130 if this is the case:
[Warning] $Main@0(#1) W130 OUT parameter #1 writing to High Speed Output Y0 that is bound to @Axis1 - Axis with Step/Dir Pulse Out - Step: Y0, Dir: Y1 (instruction has no effect)
-
No configurations on my outputs, High Speed, Table Driven, Axis, etc.
-
I'm trying to envision a single point of failure for all outputs and LEDs. Much like the outputs and LEDs, I'm drawing a blank.
From within system config, on the I/O Mappings page, does it say BX-18ED23?
-
Yes it does. All other slots Empty.
There is no "Master Output Disable" ST Bit or similar setting is there?
-
Yes it does. All other slots Empty.
There is no "Master Output Disable" ST Bit or similar setting is there?
No. I'm kinda perplexed. There are ways this could go wrong if the I/O discovery was wrong, but showing the right unit proves that worked. Still not sure what single point of failure could cause both the LEDs and the channels to not work.
We're happy to look at the unit.
-
Is there anything in my ZipLink/Terminal Block wiring that could cause the outputs to be "destroyed"? As in if I were to plug in a new BRX, it would go poof too? I don't think so, as the LED's should still be powered internally to the PLC. And I have not found anything wrong with my wiring, it's relatively simple.
Is there anything I can do to do a hard reset of sorts? Start from scratch and start over? Write a sample config file to it for troubleshooting/process of elimination?
If I order a new one today, it currently says it'll ship Friday. I'd like to keep this one for development purposes in the meantime, I don't really need the outputs just yet, I can get all the comms developed and tested in the mean time.
-
Is there anything in my ZipLink/Terminal Block wiring that could cause the outputs to be "destroyed"? As in if I were to plug in a new BRX, it would go poof too? I don't think so, as the LED's should still be powered internally to the PLC. And I have not found anything wrong with my wiring, it's relatively simple.
Right. That's why I'm scratching my head.
Is there anything I can do to do a hard reset of sorts? Start from scratch and start over? Write a sample config file to it for troubleshooting/process of elimination?
Magic handshake is always a good choice. Power down. All dips on. Power on. Cycle mode switch Term/Run/Term/Run/Term/Stop/Term/Stop/Term. Should see LED pattern change just before factory reset. If led pattern doesn't change, try the switch pattern again.
If I order a new one today, it currently says it'll ship Friday. I'd like to keep this one for development purposes in the meantime, I don't really need the outputs just yet, I can get all the comms developed and tested in the mean time.
This might have changed, but I don't think ADC sends us field returns any more, so we don't get the benefit of failure analysis. I would love to get the unit. We'll fix it and return it.
We did have a bad batch of discovery flash parts that could cause something like this. We caught them in testing (we think) and ended up replacing all of the bad parts. That might result in what you see, but the failure is that -18s report as -Ms. Your unit is reporting as -18, so that isn't the issue...presumably. The only way I can think of it doing that is if the part worked right once, then didn't. I think it gets scanned twice during initialization.
It's getting harder to do business these days. At times, you're lucky to get parts at all, and then when you do, they might be bad. We're having to consider board layout changes to support the parts we can get. :sigh:
-
It's getting harder to do business these days. At times, you're lucky to get parts at all, and then when you do, they might be bad. We're having to consider board layout changes to support the parts we can get. :sigh:
What a pain in the behind. I feel your pain (sometimes literally!)
-
Doing a factory reset, setting IP address with NetEdit, turn PLC to RUN mode, allowed me to toggle all the Y's from a DataView.
Loading my program back on there, and I can no longer force Y's to come on (I realize if they are used in logic they can't be toggled, but even a force wouldn't work).
So, the problem lies in my program, but I can't seem to find where. It's a fairly simple program.
-
Doing a factory reset, setting IP address with NetEdit, turn PLC to RUN mode, allowed me to toggle all the Y's from a DataView.
Loading my program back on there, and I can no longer force Y's to come on (I realize if they are used in logic they can't be toggled, but even a force wouldn't work).
So, the problem lies in my program, but I can't seem to find where. It's a fairly simple program.
We're happy to look at the program if you want to email to support@hosteng.com.
-
Doing a factory reset, setting IP address with NetEdit, turn PLC to RUN mode, allowed me to toggle all the Y's from a DataView.
Loading my program back on there, and I can no longer force Y's to come on (I realize if they are used in logic they can't be toggled, but even a force wouldn't work).
So, the problem lies in my program, but I can't seem to find where. It's a fairly simple program.
In the program are you using OUT or SET coils?
If the logic contains OUT coils, and they are false the output will not turn off, even if you use the Data View to set them.
-
In the program are you using OUT or SET coils?
If the logic contains OUT coils, and they are false the output will not turn off, even if you use the Data View to set them.
It's resolved. It was actually a minor bug in the PLC I/O driver.
-
Firmware update incoming?
-
Firmware update incoming?
No. It's pretty fringe. It only occurs when the user has reduced the number of Xs in the memory config to below 64. I doubt we will even change the firmware, probably will just prevent reducing X and Y to below 64. The OP was trying to recover image register memory everywhere possible and reduced X allocation to 32.
-
It's resolved. It was actually a minor bug in the PLC I/O driver.
The OP was trying to recover image register memory everywhere possible and reduced X allocation to 32.
Interesting, when does the OP find out? :P
Sorry, checked my Spam folder, there it was for the last week. Y'all and your Microsoft powered email addresses...
-
It's resolved. It was actually a minor bug in the PLC I/O driver.
The OP was trying to recover image register memory everywhere possible and reduced X allocation to 32.
Interesting, when does the OP find out? :P
Sorry, checked my Spam folder, there it was for the last week. Y'all and your Microsoft powered email addresses...
Lol...Sorry. I sent out the answer and never heard anything else. That generally means the issue is resolved.
Please confirm the fix, but pretty sure that will fix it.
-
Lol...Sorry. I sent out the answer and never heard anything else. That generally means the issue is resolved.
Please confirm the fix, but pretty sure that will fix it.
Yes that fixed it. Now I'm off to squeeze another 4 bytes out somewhere else! ;)