Created Date: February 27,2020

Created by: kewakl

Currently, I have three P3K CPUs running 'identical ' programs (except for IP addresses)

One PAC says that a ZERO value is 2.147 billion digits in size. The other two say that a ZERO is 1 digit in size.

The tag SelCap_V has a value of ZERO - as shown in the following subrung.

I replaced the CPU with a 'like ' hardware revision, problem resolved -- except for CPU COST! :mad:

Using something very similar to this

The offending CPU is Rack_1 192.168.7.1 (Grumpy) { "data-align ": "none ", "data-size ": "large ", "data-attachmentid ":128849}

All 'Rack ' CPUs P3-550

All Firmware Revs 1.1.14.39

All Software Revs 1.9.2.0

The CPU Module Info follows

Project Rack 1 Rack 2 Rack 3 Replacement CPU

REV D2 D2 D2 D2

DATE 10/17 04/18 04/18 04/18

LOT 1 1 1 1

MFG LOC 4-3 4-3 4-3 4-3

SN P3-550 P3-550 P3-550 P3-550

+17X18F027D2 +18530F007D2 +18530F012D2 +1853F008D2

The difference seems to be something that happened to the hardware between 10/17 and 04/18

Created Date: February 27,2020

Created by: kewakl

I had something like this happen also. Try breaking up the formula into two separate math instructions instead of one.

Thanks, I tried. Log by itself failed to return a ZERO.

I can try again, just not on this project. I'm just doing cosmetics for displaying volt/current on HMI. Would be simpler if I didn't already have 330+ tags on the screen.

I'm trying to consolidate multiple INT tag values and a couple STRING status messages into one STRING tag -- with decent formatting - so I gotta know how long the INTs are.

I think that something (FPGA-Code related) changed between 10/17 and 04/18. We don't get release notes on those.(?)

Created Date: February 27,2020

Created by: kewakl

Back to the bench for a test.

A simple log(0) returns 2 billlllllllion!

I think I will try some firmware upgrade/downgrade cycles. May be something glitchy in one of the FW installers.

{ "alt ": "Click image for larger version Name:\tlog(Zero) -math -simplified.png Views:\t0 Size:\t22.7 KB ID:\t128853 ", "data-align ": "none ", "data-attachmentid ": "128853 ", "data-size ": "full "}

firmware juggling did not help.Went from 1.1.13.24 thru 1.2.7.39 No luck.

Tried on a C1 CPU, it works as expected.

CPU P3-550

Rev C1

Date 10/09

Lot 1

MFG 4-3

it was a C1 CPU, not a C4

Created Date: February 27,2020

Created by: kewakl

Log(0) works on the other 4 P3-550's. So either ONE is wrong, or 4 are wrong. If the results were consistent across CPUs, I might never have noticed.

With Pseries hardware and software , I cannot really tell.

franji1 , what you say makes a lot of sense, but why do several CPUs report with log(0) ---> 0 and one takes issue? I could do a value check before the log check. Thanks.

g.mccormick I included a link in the OP for that reason https://forum.automationdirect.com/f...nd-or-truncate

Created Date: February 27,2020

Created by: kewakl

. I would do a compare ahead of the math operation to be sure the value is nonzero.

Yes. From franji and your responses, I think I shall do just that, since the result will vary from CPU to CPU. Thank you both.

Background, I am trying to pack some values into a string - I need to know each substring's length - this substring specifically must be length , but I do not want leading zeros.

This substring is the measured voltage on a capacitor (0 - 600 VDC). Reference post 3, I am running out of tags per screen on HMI.

Created Date: February 27,2020

Created by: kewakl

I might be over simplifying and not understanding what you are trying to do but couldn't you use the copy instruction to get an int to a string and then us the use the string length instruction (SLEN).

Yes, that should work, and I could. Other than another instruction and another tag....

I tried to build this string incrementally, but it seems that pac will not take a string as an argument to an instruction where the same string is the result. (like a 'CAT instruction.)

So far, the advice from franji1 and g.mc have worked well enough -with minimal code change - I just have to document this so I won't be in repeat-land.:rolleyes::o

The building of the string is not the issue, it is that different PAC hardware revs return different results.

Upon thinking (I should do this before posting) it seems that the 2.1billion is more correct than a zero - if the 2.1billion were negative, that would make sense as an error value.