I am new to this control logix stuff so bare with me. I am trying to use a BSL instruction to test some outputs, but my problem is that this instruction HAS to use a double integer. So what I used to do in the old SLC and PLC would be set a bit in a integer and use a timer to keep shifting it left, and just use a MOV instruction to move the integer to the output word. It was easy to move a 16 bit integer word to a 16 bit output word. But now with this 32 bit stuff it gets a little more complicated. I started off using the MOV instruction to the output word then after the 16 bit I had to put in a xic to ote 16 more times to get the higher part of the word. Anybody got any good suggestions?

I'm not sure I am following you, but I think you need to put a DINT in your BSL that you MOV to you output instead of and INT

I know you have to put a DINT in the BSL or when you compile it it will error out. But every time the timer gets done the BSL rung goes true which would shift the bit over one. So the next rung has the MOV which moves the entire BSL destination word right to the Local output word which is only a INT. So after bit 15 in the BSL dest. word is bit 16 but the local output word only goes to 15. Its a 16 bit output card. Make anymore sense or did I do even worse?

Can you post a screen capture of your rung or post your file? I think I am misunderstanding you



All I/O modules I can think of have 32 points even if there are only 8 physical outputs

Let me try this out. How do you do a screen capture?

I'm no CLX expert, but could you not use a timer, a counter and indirect addressing instead?
Timer done bit, indexes a counter, the counter value is used for the indirect address. Then you could limit the counter to 0-15.

Just a thought

Can you post it with you tags in the browser. I think your data types might be the problem

Oh wait. Are you trying to get the upper half of your DINT into slot 4?

Is this what you are looking for. The lower half of test2 will go into slot 3. The upper half will go into slot 4

You could move a zero into Bays_Test_Control.POS after it is EQ to 16

With a 15 in your length in the BSL you will be moving 15 BOOL's at a time.

You could put a 2 the length then skip a BOOL @ "test2"

Or try putting 32768 in the length of the Control "Bays_Test_Control.LEN"

This might stop the setps at BOOL 15. Im not sure though

The simplest sway to screen capture is to use the Print Screen button on your keyboard. This Copies the Screen you are looking at into the windows clipboard. next open Paint and paste the clipboard to a new paint file. Hint when you save select type .jpg as .bmp is much larger and just wastes space.




How about replacing your xic to ote with the following.

SOR GRT MY_DINT 16#00FF MOV 1 MY_DINT EOR

This will move a 1 into your DINT any time a bit beyond 15 is true and restart your test of bits 0 thru 15.

I have not tested this code but try this. Every two seconds the BSL will shift. The upper half of the BSL is distributed to slot 4 using the BTD.

The only problem I see is currently your BSL length is 15. I think you want to change it to 32. Otherwise you will only see bits 0-14 change and only outputs 0-14 of slot 3 will be affected

And I left the unlatch of the BaysOpen in there thought I'm not sure you want that

Bob how does the length work in the control tag.

I believe that length in the BSl dictates the number of bits to shift and in the BTD it indicates the number of source bits to copy to the destination.

I'm not refering to the length in the BSL but in the CONTROL tag itself.

By the way I cant get the Emulator to work. I selected the Emulator controler and a vitural backplane in Linx
what else do I need?

[attachmentid=2193]

BaysTestControl.Len is where the length from the BSL command is stored. BaysTestControl is the data structure which the BSL uses to accomplish the shift.

Thanks TW that is what I was looking for. Instead of a MOV using a BTD.
Thanks again guys!

Just a word of caution about the BTD instruction.

It can generate minor processor faults in a way that is not obvious. If you move a value from a DINT into an INT using a BTD and bit 15 is ON, you get a minor processor fault. It has to do with the way the ControlLogix does type conversions. For whatever reason, it trips over the fact that the value changes from a positive to a negative as a result of the BTD even though the BTD is an instruction intended to manipulate on the bit level.

In your case, I believe you will be OK. As TW pointed out, all the digital I/O modules I've used have a DINT for the output data regardless of the actual point count on the module.

For a more general solution of the problem of moving the bits from a DINT into two INTS, the COP or CPS instructions do a nice job. "COP My_DINT My_INTarray[0] 2" will split a DINT into two INTs that you can then MOV as needed without any annoying minor faults.

Just one of those things that has bit me before.

I have never ran into this and frequently BTD Dints into Ints. Can you post an example so I can play with it?

TW,

Try this. I don't have a CLX setup in the office right now to check, but this is the situation I ran into in the past. If I can get some time later I'll double check it too.

BTD MyDINT 0 MyINT 0 16

When MyDINT is greater than 32767, you should see a minor fault.

The plant I was working at the time was using version 11 firmware, so it's possible Rockwell changed it in later versions.

TW,

Update

I found someone in the office with a version 12 processor and checked it. It definitely causes a minor fault in version 12 too.

In my earlier post I said that a value greater than 32768 would cause a fault. That's not 100% accurate. What is actually the trigger is bit 15 ON. A value from 32768 to 65535 in a DINT will have bit 15 ON and that was the range I was interested in since I was only BTDing 16 bits.

I can't seem to replicate your problem. Below is what I setup and no faults. Am I understanding correctly?

TW if you then use your INt as the present of a timer or the process value of a PID you'll get an error.

I understand that, but mellis is saying with a BTD. I think someone lost me.

TW,

Your example looks just like mine.

Are you checking under Controller Properties, Minor Faults tab? This isn't going to turn the "Online" box red and say "Fault". It's just going to log a minor fault each time it happens. It doesn't halt the processor, just wastes processor time.

What firmware version are you running? I still haven't checked under 13 or 15 yet. But I'm betting they are the same.

Now like Bob says, stuffing a negative number into a timer preset will get you a major fault. But that's a different story.

Yes, checked the minor faults tab. No fault. I tried on version 15 but I'm pretty sure that I have been doing that same thing since version 10 or so.

Can you post a sample program that is doing it? May be I'm missing something you are saying.

TW,

I don't think it's the program. It's just one instruction. And I can see by the data that the source is a DINT and the dest is an INT. I can also verify that it is the same bit pattern in both tags. Can't imagine how there could be a problem there.

I'll see if I can flash the processor I have to ver 15. The guy who is using it will probably not like that idea much <eg>.

The only other thing I can think of is processor model? I've seen this in L1 processors and the one I checked today is a L55. What are you using?

I really didn't expect this to turn into a discussion, but now I am really curious as what exactly is going on here.

This is the kind of question the Rockwell forum was actually pretty good at. Someone like Ron Bliss would pop up with a definitive answer. I'm going to miss that.

I would not be suprised if they were not here somewhere.

I tried it on an L55. I'm not doubting you but apparently I'm just not following you. There is not chance that your destination bit was greater than zero or you length was greater than 16 is there. Or am I way out in left field

I've got L1s and L55s doing BTDs in the same manner. Thats why I am confused. I may need to put something in mine to keep this from happening. But I got to make them do it first, thats why I'm trying to make sure I fully understand

I did not follow this discussion from beginning, but as far as I know in every version of logix every time you put into the integer tag a value with bit 15 set, it will generate minor fault "Overflow". You may just ignore it or reset it.
It's always recomended to use DINT for all calculations including 16 bit processing.

Ok, guess I need to hunt and figure out how I have never managed to set bit 15

Actually I was not correct:
If you are using BTD, no overflow will be generated as this is just a bit pattern.
Same with COP instruction, as it copies a bit pattern without checking a value.

But if you are using MOV <DINT> to <INT> and DINT >32767, then overflow will be set, but result will be the same as BTD

(Type 04) Program Fault
(Code 04) Arithmetic overflow. Result of an arithmetic instruction out of range.
Task: MainTask
Program: MainProgram
Routine: MainRoutine

Here is definition:
Overflow is set if the value you are storing cannot fit into the destination.
Either the value is greater than the maximum value for the destination
or the value is less than the minimum value for the destination.

Mellis - Is it possible that somewhere else you are manipulating that same integer or double integer somewhere else that is actually causing the minor fault? May be an ADD or MUL.

Can you post a program?

TW,

I really don't think there is any difference in our code. Here is what I did to test:

Went online with a L55 and added a rung in main routine with a BTD instruction only. (there was a program running already)

BTD MyDINT 0 MyINT 0 16

Created two new tags MyDINT and MyINT of type DINT and INT.

Accepted the rung.

Entered a few numbers below 32767 into MyDINT and observed that they transferred to MyINT with no changes.

Checked that I had no minor faults.

Entered 32768 into MyDINT and observed MyINT showed -32768.

Checked for minor faults and I had a program fault of exactly the type Contr_Conn described in his post, Arithmetic Overflow.

Repeated the process a few times to verify it wasn't a coincidence.


So, here's what we know at this point:
It definitely faults a rev 12 L55. (I believe it faults a rev 11 L1, but I can't test it right now)

It doesn't fault a rev 15 L55. (I believe you too)

I'm leaning towards the idea that it got fixed in rev 13 or 15 but I can't confirm it without flashing the processor and the guy who is using it is not going to let me do that right now.

The only other action I can do right now is call tech support, but I'm still going to want to see it with my own eyes before I consider it resolved. But I'm afraid I'll have to backburner that until I get access to a processor with newer firmware. If you get a chance to check it in a rev 11 or 12 processor before then I'm certainly interested in the results.

I will check revision notes to see if they change it from 12 to 15

Ver 15 works as I expected.

Let me try the latest FW in ver12

I will have to back flash one of my processors Monday but I know I have had that code in mine to do the BTD from a DINT to an INT since revision 10. I checked my logs today. I may have gotten lucky and bit 15 was never high but I am seriously doubting it. I will report what I find

Here is what I found:
Ver 12 and 13 and may be earlier(?) will set overflow minor error if using BTD instruction,
Ver 15 will not set overflow bit

This is apparent change in v15 (or maybe 14 - I did not test 14, but it should act like 15)

COP instruction will not set overflow minor error in ver 12-15 (and may be earlier - I did not test)

I went over release notes and did not find anything about this change.

Edit: I did all testing with L63/A processor and current FW available for download from the website

Well after I look closely at my programs, the BTD that is doing this is used to send messages to older SLCs that don't support Long Integers. And guess what, I can't come up with a normal combination in my code that would have set bit 15. It's possible I dodged the bullet all this time.

Hey don't say it too loud or someone will be after your pot o' gold.

I know. I am never that lucky. I can find no code that intentionally keeps bit 15 from being set but I can find no scenario that would set bit 15.

Contr_Conn,

Thanks for taking the time to run the test and share the results.

It's nice that they changed this in rev 15, but you would think it qualified for a revision note. I checked the revision notes too and came up empty.

I did some research - this is considered as incorrect operation of BTD in earlier versions and v15 officially fixes this. It is not a functionality change Ii guess...