Hardware or Memory Error with Analog Outputs?

[dbgg]

Hello,

I'm trying to make a simple 8-step sequencer which writes a value to a block of analog outputs WY8-15. These are connected to 0-10V controlled LED dimmers. The goal is to have each LED turn on and then off in a sequence, and then start over. I'm using the Do-More T1H-DM1E PLC and T1F-08DA-2 analog output modules.

The problem is that the last step of the sequence (WY15) is "latching on" - the LED stays on and the analog module is outputting 2.5 volts constantly. However, the status bit in the Data window shows WY15 equal to 0. So I have 2 problems:

1) The status of WY15 in the Data window is not consistent with the physical/electrical output WY15. The status window shows correct on/off behavior, while the electrical output is latching on.
2) If I copy WY15 to a different analog output with a MOVE instrution (for example, MOVE WY15 -> WY0), the behavior of the MOVE instruction is also inconsistent. In this case, the copied output WY0 shows the correct on/off sequencer behavior, while WY15 remains latched on. This leads me to believe there is an internal hardware/memory error, since WY0 should be exactly the same as WY15 at all times.
3) If I copy the whole block WY8-15 to WY0-7 using the MOVER instruction, the copying behavior is also inconsistent, but in a different way. Now, the first 7 outputs of each block appear to follow the correct on/off sequence. Now, however, copying WY15 to WY7 (as part of the MOVER instruction) latches both on. After several cycles, one or the other will turn off in (in the correct sequence order), but WY7 and WY15 do so at different times, on different cycles. So the MOVER value copying is again inconsistent, leading me to believe there is an internal/memory error in the PLC.

I've tried all sorts of things, including swapping different CPU's and swapping the order of the analog modules, as well as inserting/removing other modules before and after in the chain. The only thing that remains consistent is that it's the last step of the sequence which latches, if I change the counter preset value.

I'm attaching a small sample of the code, which uses the counter CT0, and I'm showing only the first 2 steps of the sequence. Any help is greatly appreciated!!

NOTE: I've also posted this on the AutomationDirect forums, apologies for the double-post:
https://forum.automationdirect.com/forum/general-applications/103146-hardware-or-memory-error-with-analog-outputs

Please see attached image or the above link (sorry I'm having trouble figuring out how to display it with the [img] tags).

[BobO]

Not an internal memory error, l'm certain of that. This does sound familiar though, like a bug that should have been fixed. What firmware version is your CPU?

[dbgg]

Hi Bob,

Thanks for your reply. I'm attaching a screenshot w/ the PLC Info window.

[BobO]

Seems like you are up to date. I'm currently out of the office and won't be back until next Friday, so I can't check the code...but...I think this may have been fixed but not released due to us being in the middle of the development cycle for our new hardware product. I do think there is a workaround though.

If my rememberer is working right, the issue is in analog output data being written that isn't changing...The module driver is being too clever and writing only changes, but isn't working right.

The simple workaround is to do a small dither on the output. Meaning, add a small offset to the output value to force updates...like plus or minus 1 count. I'm almost certain that will cure it. We probably should've gone ahead and did the work to put out the release when it was discovered, but the customer that found it was happy with the workaround and it was never mentioned again. Honestly, I had completely forgotten it until your post.

[BobO]

If it wasn't obvious from my previous post, the dither needs to be time varying. A simple approach is to use a MATH box with something like WYx = TargetVal + (TICKms() & 1). If you need to use 65535, the dither needs to be subtracted, otherwise it will flip back to 0. If you want a slower dither, the term can be something like ((TICKms() >> 4) & 1).

If you are using a sequence or state machine to drive the output, drive an intermediate value instead, and put the dither code in tBottomOfScan.

[dbgg]

Hi Bob,

Thank you for the suggestion. I tried a quick workaround that alternates between writing 0 and 1 to the final WY15 output, which seems to fix it on first look.

One note is that using the $ScanToggle timer is too fast, and introduces errors on other outputs (many latching outputs instead of just 1). This is while toggling ONLY one output WY15, and ONLY in the WY15 = 0 "off" state, not during the WY15 = 1023 "25% on" state.

It does seem to fix the bug using the $50ms timer to toggle the dither.

When will a firmware update be available to fix this bug? Our proposed application might have on the order of hundreds of analog outputs.

[Controls Guy]

This is odd.   Why does it pick random channels to do this and not all?

[dbgg]

I'm attaching a screenshot of my workaround code. This is only applied to 1 output (WY15) and toggles the output between 0 and 1 in when it should be OFF (that is, when CT0.Acc != 7).

This replaces the function of the rung in the original code with the CT0.Acc != 7 test.

With rung 64 set to $ScanToggle, multiple outputs are misbehaving unpredictably, but I haven't touched the code for any other outputs.

However, if I change rung 64 to $50ms, it seems to correct the original bug without introducing new ones.

I'm working on applying this fix to all 16 outputs to see how it works. Just to clarify, it's usually the last output in the sequence which latches on.

Also, AD tech support just recommended upgrading the PLC firmware to 1.4.2; would that fix the problem?

[plcnut]

You should probably update your firmware. It may not fix the issue that you are dealing with now, but it will fix other issues.

[BobO]

I'm out of the country until Friday, so I can't check any of the specific details until then.

It's always best to run the latest firmware. I have been so deep in new development I can't begin to remember what was fixed when, except to say that if this is what I think it is, it's already fixed, but may not have been released.

The short answer is 'yes', we will certainly release a fix if 1.4.2 doesn't already contain it.

As for the workaround, I wouldn't make it event based, I would use a time based dither value and continuously drive it, just as I described in my previous post.

[dbgg]

Ah, yes, a firmware update to 1.4.2 seems to have done the trick. I didn't even think of that because 2 different tech support people told me it was up to date.

Thanks for all of your help!

[plcnut]

I didn't even think of that because 2 different tech support people told me it was up to date.

Your old version number was the latest for the H2-DM1E, but the T1H-DM1E had a newer update. It confused me too.
Glad you got it going!

[BobO]

So it was released. Good.

Sorry for being next to useless. Stuff like this is a 5 minute check when I have access to version control.