Migration from Allen Bradley ML1500 to ML1400 S:/0 Error

[JasonCES]

I have a Allen Bradely 1500 that has a cracked board. It still works but needs replaced (battery is no longer connected). To make migration easier (so I thought) I choose a 1400. Copied program from 1500 into a new 1400. Put the system into run and get a S:5/0 Over flow Trap error. Put the 1500 back into the system until I can figure out what went wrong. It happens when a Load cell to PLC converter Feeding a High speed counter exceeds 3277Hz. The program does a ton of math on this info. Tried using the trap error bit to set a bit to find where in program Might be a problem but it moves around where it errors. Why does it work fine in a 1500 and fails in a 1400? THanks for the help in advance.

 

[drbitboy]

3277 is almost exactly 10% of 32767, so it is likely that "ton of math" is the cause of the problem. can you move the data into LONGs or better yet floats and do the math there?

I am basically making the same guess as this post* by tailbalance on reddit: https://www.reddit.com/r/programming/comments/1mtsoy/comment/ccclm5a/?utm_source=reddit&utm_medium=web2x&context=3

* which post hit the nail exactly on the head; I've seen the code.

 

[OkiePC]

That's interesting. Did you simply change the processor type, verify and dump the converted program into the 1400 with no other changes?

Can you share the original and converted programs here? (zip them first before attaching them to a reply).

As a bandaid, you can clear the math error bit at the end of scan in the MAIN (LAD2) program. I frequently do this to keep a PLC running when I know it's okay to live with errors that might be due to scaling error on a failed sensor, for example.

You can put a run like this with a unique B3 address in multiple places in the PLC program in order to nail down the root cause(s) of the math overflow errors.

EDIT: I reread and it sounds like you've already done all this.

Is the HSC counter set up correctly in the 1400? I don't think I have used the HSC with a 1500, but it would not surprise me if there are differences that didn't properly convert.

 

[Ken Roach]

Welcome to the PLCTalk forum community !

I couldn't write up a comprehensive list of the technical differences between the MicroLogix 1500 and 1400, but there are a few that might matter, especially with the different High Speed Counter / Output features on the two platforms.

The SLC-5/02 operating system was the basis for the MicroLogix 1000, then the 1200, then the 1500.

But the MicroLogix 1100 started almost from scratch: it's compatible and similar but not really based on the older SLC and MicroLogix OS'es. The 1400 is based on the 1100.

Describe how your high speed function works, and examine that "ton of math" that results in a frequency target that is probably an ordinary N-file integer that will overflow when it exceeds 32767.

If you can, ZIP and attach one or both programs.

And again, welcome to the PLCTalk forum community ! This is a neat challenge.

 

[Ken Roach]

After a little more thinking: if there's a subroutine being executed by an HSC event or time-driven (STI) interrupt and the instruction responsible for the overflow condition occurs there, it might be difficult to use logic in ordinary subroutines to trap it.

 

[JasonCES]

It was just change processor type and load program from 1500 into 1400.

I have thought the HSC and walked through both Original 1500 program and my converted 1400 program and couldn't find any differences there. I will have to get the program when I am at the shop again. Thanks for the Help so far. Yes I have tried the unlatch S:5/0 at the end of scan but it still errors. Keeping me leading back to the HSC.

The PLC uses a Calex Model 6255 strain gage to PLC high speed counter to produce a Counts per second = LBS of materiel to mix product.

 

[Ken Roach]

I'm very interested in how the strain gauge interfaces with a High Speed Counter.

My guess (it's just a guess !) is that there is a signal converter somewhere in the mix that converts a raw strain gauge millivolt signal to a pulse train. I remember years ago using those with MicroLogix because they had HSC's but not analog inputs.

 

[JasonCES]

Sorry it has taken so long for me to get the file around. Here are my two porgrams.

 

[OkiePC]

My first thought after doing a "Find all" on HSC:0 and HSC:1:
"That's some goofy chit right there."

Every 1 second, (STI LAD 7) let's multiply HSC:0.ACC by ten and store it in HSC:0.ACC, copy it to L31:14, then reset it.

Repeat process for HSC:1.ACC.

Not sure what the thought process is, but there is always a risk that in between instructions, the HSC value changes since it runs asynchronous to the PLC scan. Same with the STI. It can break in at any point in the logic and run.

I don't know if that is where or why you are getting a math overflow. I don't think there would be any difference if you changed the destination of the MUL instructions LAD7 to L31:14 and L31:17 and delete the MOVs on that rung, but it would be cleaner, in my opinion, than directly writing to the HSC accumulators and running the risk that they increment between instructions on that rung.

I would expand the B3 file to 32 words (or add a new Bit file with at least 4 words) and put the Math Overflow Trap logic described earlier in each LAD file with a unique trap bit for each file.

You have 34 ladder files and a shedload of indirect addressing in this undocumented program, so chasing down the error might take a bit of time and effort.

 

[drbitboy]

Every 1 second, (STI LAD 7) let's multiply HSC:0.ACC by ten and store it in HSC:0.ACC, ...

There's your bug: 3277 * 10 = 32770, which is greater than 32767, the signed 16-bit integer after which math faults occur.

Who wants to bet against me saying that HSC:0.ACC in the old machine is a signed 32-bit Long, and in the new machine it is a signed 16-bit integer?

 

[OkiePC]

There's your bug: 3277 * 10 = 32770, which is greater than 32767, the signed 16-bit integer after which math faults occur.

Who wants to bet against me saying that HSC:0.ACC in the old machine is a signed 32-bit Long, and in the new machine it is a signed 16-bit integer?

The HSC accumulator is a long integer (32 bit signed) in both processors so that isn't the overflow, and if it resets every second, I'd be hard pressed to think that it ever reaches a value that is one tenth of the range of the long integer destination that it is being stored in. I didn't find anything that would disable the STI either.

With the length of the program and lack of comments, I still suggest inserting overflow traps in various files and narrow it down until you can find the offending instructions(s).