Real Tags not computing in ControlLogix

I got a weird problem with getting real tags to compute properly on an L63/B. I've tried firmware 15 and 17 with no success. I've created a brand new app with only the 3 rungs shown in the picture below. Any idea?

That is weird. I did a search on the AB/RA Knowledgebase, and did not find anything except for one that applies to an early unit with V11 Firmware. KB53436 Tagged for everyone.

Time to call AB Tech Support I think.

Stu....

In rung one place your cursor on the value shown under zreal3. Type 3.14 and press enter. Does the value change? Does it stay that value? Now go to zint3 on rung 0 and change the value to 5. Does it stay at 5? If the answer is yes to those questions then chances are good that your routine is not being scanned.

Can you zip the program and attach it to a post?

No, definitely logic is being scanned. I don't have a problem with integers, just reals. The processor is brand new in a box with factory seal but it has been sitting on the shelf for the past 5 years.

Something like this came up before, and if my memory serves I think it was down to video drivers.

Can you post a screen-shot of the tags in the database when that code is running ?

PC video driver? I went online with 2 different computers and same thing. I think I partially brick this somehow when I flash it with version 15 the first time. It didn't work with version 20 as well.

Just flashing my L62 to V20 now to test this......

All looks fine to me....

running on an L62 flashed to Rev. 20.11

"Partially Brick" should get cleaned up with a new flash, to any revision...

The L6x series reduce to "out-of-the-box" revision (1.9?) if flashing fails, for whatever reason. It then can be flashed again.

From the screenshots and ACD file you have given, it does appear to be a "bad" module, and if it's been sitting so long, it's definitely out of the warranty period, but talk to your rep nicely.....

If it's identified to be a production issue (there were some logix5000 processors with chip issues, although I thought they were L5x series), they may replace it... negotiate with them.

Using ControlFlash must not invalidate any responsibility on their part, as they force you to do it anyway with a new processor.

I bricked a Compactlogix by forgetting to turn off BootP prior to controlflash. At some point, the process called for a reboot at which point BootP broke the connection to finish the firmware update. I had to leave it off with the battery out for a long time to get it to revert back to boot firmware, no problem right?, now I flash it again and all is perfect right?

So the 2nd time around I made sure the bootp did get turned off and stayed turned off, updated it to the required (v17?) level and away it went.

Then it started having brain dumps. It would run and perform flawlessly for four hours, then would either cease communication (and appear to keep running) or fault and dump its memory.

Then it was two hours, then 30 minutes, and it stayed there. I was trying to develop the scale application on my desk with clean UPS power and it would fault and shut down every 30 minutes. I could dump the program back in and test some more. For the longest time I chased my tail thinking it was something wrong in the UDT I had just added for a scale module. But after two days of this...

I probably caused it, and my distributor got them to exchange it at no cost.

I, too, remember a thread about the display of reals and false info caused by the video driver. It sounds crazy; that's why I remember it...will see if I can find it...

EDIT: This might be it.

That was indeed the thread I had in mind, but it seems it was never conclusively "closed" with a resolution, although it did strongly hint at video drivers on the PC.

In your case, DaveW, is it possible the 2 different computers you tried have the same video card and driver software?

Ken's comments about putting "trap" code in, to see if the displayed values are actually what is in the tags, is wholly relevant, and a sure-fire way to determine where the problem lies.

Also see what the mouse tool-tip says the "erroneous" values are, as I noticed the tool-tip showed them correctly.

Also you get the same bad displays with different firmware revisions of the controller. This strongly suggests that what you are "seeing" is not what is happening in the controller at all.....

Wow, not turning off bootp can cause a compactlogix to brick! I guess I've been lucky all these years never having bootp running because the PLC always has an IP address when I load the firmware.

I think this L63 is somewhat toast. It's not a video display problem. I can use reals in compare instructions and read and write to them with a PanelView or Excel. It's just that if I try to use a math instruction the results are unpredictable. I guess I will save this CPU for a large project that doesn't require math with floating points.

I think this L63 is somewhat toast. It's not a video display problem. I can use reals in compare instructions and read and write to them with a PanelView or Excel. It's just that if I try to use a math instruction the results are unpredictable. I guess I will save this CPU for a large project that doesn't require math with floating points.

Click to expand...

Steady !! Before you do that, think about the implications.

I believe, but not based on in-depth knowledge....

... that the "firmware" you load determines how the processor handles math instructions, not the hardware, which is just a microprocessor running an operating system. The O/S does the maths, by running code, not the CPU.

Have you done any of the "trap" tests, or hovered the mouse over, as suggested ??

Flashed to 3 different firmwares with same results...unless all my firmwares are bad or corrupted.

Like I said, compare instructions works (ie GRT, LES, EQU).

MOV works.

DIV, MUL, ADD, SUB, CPT doesn't.

PID doesn't because I guess lots of calculations there.