Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: RBPLC on June 15, 2021, 08:01:55 AM
-
Remote 1 EBC-100 with a BX-08UT module in slot 1 is reporting an error. There are 6 TC inputs into this module with the last two channels disabled. The six active channels appear to be reporting correctly. No bits are flagged. I cannot seem to clear the warning message and the I/O monitor provides no useful information. What's the potential issue?
-
Remote 1 EBC-100 with a BX-08UT module in slot 1 is reporting an error. There are 6 TC inputs into this module with the last two channels disabled. The six active channels appear to be reporting correctly. No bits are flagged. I cannot seem to clear the warning message and the I/O monitor provides no useful information. What's the potential issue?
The EBC latches some of the error info and doesn't clear until told to. Necessary, because it's remote. It should clear though. What is the System Status page of the System Information dialog showing you?
-
ST152. This will not clear.
-
ST152. This will not clear.
What's in DST28?
-
2
-
I don't remember exactly when the remote gets cleared. The guy who may remember more than me is out today. We'll talk about it when he's back in tomorrow.
-
Any guidance?
-
Any guidance?
If the I/O System view isn't giving any useful info (i.e. no slots are showing warnings or errors), but the PLC is reporting an issue on the I/O slave, then we'll probably need to get you talking to a support tech here to dig a little deeper.
-
Something seems to be up with the 08UT's reporting. I've got another system I'm working on with one remote EBC with a single 08UT with three TC's installed. When I unplug one of the TC's (or multiple) I get a warning in DMD but when I open the I/O system view, there's no warning/information showing there.
-
Have you guys had a chance to look into this? I'm looking to start a larger integration soon and would prefer not to have to deal with this.
-
Have you guys had a chance to look into this? I'm looking to start a larger integration soon and would prefer not to have to deal with this.
The only issue we find is that apparently the reset process that occurs as part of startup is taking 103ms, but the default slave timeout is 100ms. At 104ms, everything works fine. We need to look into why that is, but for now try increasing the timeout to 150ms.
-
On the two I currently have, 1 slave timeout is 500ms and the other is 1000ms.
-
On the two I currently have, 1 slave timeout is 500ms and the other is 1000ms.
Then (so far) we can't dupe what you are seeing. Errors come and go as expected in the I/O View.
-
Attached is what I'm currently seeing on one of the systems.
-
What version of Do-more Designer are you using?
2.7 and earlier definitely had issues reporting BRX I/O Errors, which were fixed in Designer 2.8. The latest Designer version is 2.8.3.
-
What is the value for X16:UW (i.e. the 16 bits of X16 thru X31 as an UNSIGNED WORD)?
You can enter that in Data View.
-
Currently running 2.8.3 Production. See the same thing on two computers. One running Win10 the other Win7. X16:UW is 0. No individual bits are showing on.
-
can i assume the firmware in your BXEBC100 is up to date (v4.2.133) it needs to be at least v4.2.120 or later as we fixed an error reporting issue in that version.
i haven't been able to dup this problem using your arrangement of modules, so if you're game i'd like to try single stepping through the setup to see where the problem shows.
the EBC100 can only have one master, so you'll need to temporarily disconnect your CPU as the master by powering the CPU down or unhooking the ethernet cable from the master.
then fire up the Do-more Simulator and configure it to be the Ethernet I/O master, add that ebc100 as the slave - but don't configure the UT yet - simply add the slave (remember to increase the Timeout in the Slave Config to 150ms), save the config, download it to the Sim, and go to RUN to see if that works with no errors or warnings.
if that works cleanly, configure the UT module as it should be, 6 channels enabled and proper probe type. then save the config, download, and see if that still works cleanly.
if we're still good, then induce a problem - remove one of the wires from one channel - that should cause a warning. Open the I/O System view to make sure it's the right channel showing the warning. then replace the wire and see if that warning goes away.
If the I/O System View is still open, the warning should clear itself.
If the I/O system View is NOT open, the warning will remain until you manually clear it.
-
can i assume the firmware in your BXEBC100 is up to date (v4.2.133) it needs to be at least v4.2.120 or later as we fixed an error reporting issue in that version.
Yes. v4.2.133
then fire up the Do-more Simulator and configure it to be the Ethernet I/O master, add that ebc100 as the slave - but don't configure the UT yet - simply add the slave (remember to increase the Timeout in the Slave Config to 150ms), save the config, download it to the Sim, and go to RUN to see if that works with no errors or warnings.
Setup the slave with the three installed modules shown in posted photo. Poll rate 50ms, timeout 150ms. Without setting the 08UT up, download to controller and get the warning message indicating "This module is reporting an error". Configure 08UT with 6 TC's, re-download, seems to be reading correct temperatures but with warning message still displayed.
-
This tough, i have exactly that layout and can't duplicate what you're seeing.
I did notice one difference in I/O System View that may be a clue, when i induce an error on the one channel i have configured, i see text expounding on what the actual error is:
-
Without unplugging the 6 TC's that I currently have installed, if I change all channels to 10k thermistors as you've shown, I get out of range and burn out errors for channels 7 and 8. For reference, when I do this, the error bits show up as well.
-
are you familiar with Wireshark - the ethernet packet trace software? we use it to debug the packets between ethernet clients and servers. Would you be willing to try to capture a packet stream between the SIM and the EBC100 so that we can see what questions the SIM is asking and what answers the EBC100 is giving.
What appears to be happening is the EBC100 is telling the CPU that is has a problem with one of the modules, but when CPU queries the EBC100 for the error/warning information there's nothing reported. Seeing the contents of the packets gives up the ability to trace back through the code to see what's going wrong.
-
I've only briefly tried out wireshark. Never attempted to capture info. I don't mind trying, it's something I need to add to my toolbox. Is there be some other firmware/booter/configuration setting that I need to check?
-
no other configuration settings of concern, that's the reason i wanted you to use the Do-more Simulator as the master, so there'd be a clean sysconfig and no ladder program that could be interfering in any way.
pretty much all you need to do is get the simulator running and showing the warning that won't go away, then start Wireshark, click the shark fin button on the toolbar to start a capture, let it run for about 10 seconds so that it will capture several transactions between the SIM and the EBC100, then click the red square to stop the capture. save that trace to a file then email it to us at Support@Hosteng.com.
-
The attached is a third system running with the simulator with a EBC with firmware version 4.2.123. One image shows all channels configured for TC with no TC's plugged in. All the error bits are present but nothing in the I/O monitor window. The other image is with only the first input configured for TC with no TC's plugged in.
-
I've emailed two different Wireshark captures for troubleshooting purposes.
-
I've emailed two different Wireshark captures for troubleshooting purposes.
We looked through the traces. It appears that the module status function wasn't returning all of the errors to DmD. Not sure if this is *the* error, but it appears to be *an* error. We've fixed it, and can send you new EBC firmware if you'd like to try it.
-
Yes. I've got time to try them currently as my systems that these are installed on aren't running at the moment.
-
Yes. I've got time to try them currently as my systems that these are installed on aren't running at the moment.
Same email as the traces?
-
Yes.
-
Well,
To get you started, I installed the beta EBC firmware that you sent (referencing the system shown in ModuleError.png that I uploaded). After updating, it cleared the error in the I/O system window that I had been seeing associated with the 08UT. Then it brought up errors for the next module, the 8 channel 8AD on channels 7 and 8. When I set up the AD I only had 6 of the channels hooked up to sensors. Channels 7 and 8 I believe are currently open. It was reporting channels 7 and 8 being out of range as they were left set-up to the (I believe) default of 4-20 mA. I went in and changed these channels from 4-20 mA to +- 10V and these errors went away. This got me to thinking, why is there no option to disable AD channels like there is for 08UT channels? It appears that part of the problem that I was seeing had to do with incorrect reporting of errors that were on a different module. Does this make sense based on the changes you made?
*Edit: The error reported was Channel Failure, not Out of Range on the AD module.
-
Well,
To get you started, I installed the beta EBC firmware that you sent (referencing the system shown in ModuleError.png that I uploaded). After updating, it cleared the error in the I/O system window that I had been seeing associated with the 08UT. Then it brought up errors for the next module, the 8 channel 8AD on channels 7 and 8. When I set up the AD I only had 6 of the channels hooked up to sensors. Channels 7 and 8 I believe are currently open. It was reporting channels 7 and 8 being out of range as they were left set-up to the (I believe) default of 4-20 mA. I went in and changed these channels from 4-20 mA to +- 10V and these errors went away. This got me to thinking, why is there no option to disable AD channels like there is for 08UT channels? It appears that part of the problem that I was seeing had to do with incorrect reporting of errors that were on a different module. Does this make sense based on the changes you made?
*Edit: The error reported was Channel Failure, not Out of Range on the AD module.
On the FACTS built modules (-1 and -2B), there is an option to change the number of channels enabled. The number of channels enabled affects performance and will show errors for disconnected channels (-1).
On the Host built modules (-3), the default setting is voltage (0-5VDC), not current, and due to parking resistors, shouldn't give an error if disconnected. All channels enabled doesn't affect performance, so we didn't feel like the added complexity was necessary or beneficial.
On the UT modules, there are numerous things affected by how channels are configured, so it was important to start fully disabled.
-
Well to confuse the issue even further:
Channels 7 and 8, when set at 4-20 mA return constant faults for those channels with a "Channel Failure" fault. When those channels are set at 0-10V, the fault bits for those channels are cycling on and off intermittently and reporting a "Channel out of range" fault. The indicated voltage with this setting is 1.13V on both channels. When those same two channels are set -10-10V there are no faults for those channels and the reported voltage is 0.63 volts on both channels. Setting them 0-5V causes the same intermittent faults and setting them -5-5V causes no faults.
-
With it in a bipolar mode, and the inputs grounded, what does it read?
-
It'll be a while before I can get into the panel to check this.
-
I just published new firmware (v4.2.134) to our LiveUpdate server that fixes the problem of the BX-EBC100 returning the wrong slot number for modules reporting an error or warning, (the slot number is off by one). You can get this firmware update in NetEdit3 by using the File->download Newest Firmware (LiveUpdate) menu selection.
At your convenience, you should update your EBC100 to use this version instead of the beta version.
-
Any idea with analog issues I'm seeing. Is this a hardware or software thing?
-
Any idea with analog issues I'm seeing. Is this a hardware or software thing?
It's really neither. An ungrounded high impedance voltage input is showing out of range because it's going out of range due to noise. In general this hasn't been an issue due to the parking of the input amplifier (first report I've heard), so I'm just wanted to ensure that when grounded, the input shows (near) zero and stays at zero.
It's really best policy to ground high impedance inputs, just to prevent them from wandering. Alternatively, put them into +-20ma mode. The current sense resistor will park them.
-
I was trying to tie the fault reporting issue and the analog issue together (can't see the forest for the trees type of thing). It does appear to be a noise issue. When in -10-10V mode, I'm seeing cyclic counts of -8300 to 12300 counts. When in +-20mA mode I'm seeing -70 to 70 counts.
-
I was trying to tie the fault reporting issue and the analog issue together (can't see the forest for the trees type of thing). It does appear to be a noise issue. When in -10-10V mode, I'm seeing cyclic counts of -8300 to 12300 counts. When in +-20mA mode I'm seeing -70 to 70 counts.
-8300 to 12300? That's quite noisy. They park above zero due to (insert electrical engineering jargon here), hence the asymmetry in your noise range, but at 10 megaohms it doesn't take much noise to move them. Grounding is best, but the current sense resistor parks well enough.
As I said, I've never heard anyone complain, but maybe we need to investigate whether ADC deals with calls on this. We could add a disabled option, but honestly, it's better to tie them rather than letting them flap in the breeze.
-
As far as I can tell, I haven't really seen any issues with sensors that are actually connected. When I can, I'll ground them to see what that does. Maybe have the default set to +-20mA? When I was initially commenting on the fault bits, I had the filter set at 2 seconds and I couldn't see the noise. The voltages I was reporting (with the noise) were through the 2s filter. To see the noise I set the filter at 0s.
-
As far as I can tell, I haven't really seen any issues with sensors that are actually connected. When I can, I'll ground them to see what that does. Maybe have the default set to +-20mA?
That's the best in that it parks and doesn't ever generate a warning, but it's the worst in that it's the least common mode. So uncommon that we got funny looks from many involved people when we added it. :o