Bit shifting?

tlvaun

Member
Join Date
May 2002
Location
Tennessee
Posts
38
Hello,

I have a project at work where I am to set up an alarm sequence. What they want is to have the last two alarm lights that came on to be flashing and the rest to be on solid. I have been practicing this at home with an mitsubishi fxo plc using 5 inputs and 5 outputs for my sequence (at work they will be about 20 alarm lights and it has an A0J2 plc). Right now I've got it to work if everything goes in sequence (1st light that comes on goes off 1st etc.) which won't happen and also if the same alarm light goes on back off and on again it sets the last alarm light although it is still one of the last two alarms 🔨 . At last count I've got 85 steps of spaghetti code. Any push in the right direction will be appreciated.
 
"Verrrrrrry Interrrresting.... But, ______ !"

Sorry, couldn't help it! I really mean it when I say "very interesting". But, there really is a problem with the "question".

There is NO WAY to accurately monitor and indicate the conditions as you describe. In fact, it is Logically Impossible !! And if you think about it for a few seconds, you might see that, that particular approach to alarm indicating is Locically Irrational!!

Logically Impossible because...
How do you handle 3 alarm conditions occurring on the same scan?

Logically Irrational because...
Why would you be more interested in the resulting alarm conditions than the casual alarm conditions?

I should (and do) think that the operators would be more interested in knowing why they were shut-down. Two flashing indicators associated with the last two modules of a process only tells me that those two modules are not running (or working, or whatever) as a result of some "causal factor".

ALARM SCHEMES:
There are five possible Alarm Schemes...

Case-1:
A fault condition at a particular place in the process causes the local-module and all up-line (Infeed**) modules to stop.

Case-2:
A fault condition at a particular place in the process causes the local-module and all down-line (Outfeed**) modules to stop.

Case-3:
A fault condition at a particular place in the process causes the local-module and all up-line (Infeed**) modules AND all down-line (outfeed*) modules to stop.

Case-4:
A fault condition at a particular place in the process causes the local-module and some up-line (Infeed**) modules AND/OR some down-line (Outfeed**) modules to stop.

Case-5:
A fault condition at a particular place in the process causes only the affected local-module to stop. Your code MUST be written so as to handle this condition... It wouldn't do to have an up-line module jamming product down the throat of a non-functioning module!

** INFEED & OUTFEED
In this context, the terms Infeed and Outfeed are Relative. That is, anything up-line from a particular module is considered INFEED to that particular module.

Likewise, anything down-line from a particular module is considered OUTFEED from that particular module.

The particular Alarm Scheme you use is entirely dependent upon the nature of the process! In some cases, a fault at one place does not necessarily constitute a fault at other places... or maybe it does... it depends on your process.

I develop and maintain code for a process that is 4-stories tall and 2-city-blocks long. In that code, I've used ALL of the above listed Alarm Schemes. The one that gets employed, at any particular time, depends on the nature of the fault and where, in the process, it occurs. In some cases, a particular fault requires that I execute a Controlled-Crash-Stop. The idea being, don't create more problems than you already have.

When a fault condition occurs, I should (and do) expect to see solid indications that "affected" modules have stopped.

At the same time, I expect to see a flashing indication showing the location of the CAUSE.

If the physical sequence (layout) of the indicators actually follows the physical & logical layout of the process, then, when an alarm (fault) condition occurs, I would expect to see a number of solid indications and a single flashing indication.

Depending on which "Alarm Scheme" you are using, you might see something like this...


S = Solid F = Flashing X = No Indication

PROCESS FLOW -->

Up-Line Down-Line

Case-1: Local and All Up-Line Modules Stop
S S S S S F X X X X X
-or-

Case-2: Local and All Down-Line Modules Stop
X X X X X F S S S S S
-or-

Case-3: ALL Modules Stop
S S S S S F S S S S S
-or-

Case-4: The Local and particular Up-Line and Down-Line Modules Stop
X X X S S F S S S X X
-or-

Case-5: Only the Local Module Stops
X X X X X F X X X X X



.

At last count I've got 85 steps of spaghetti code.

The very fact that you have spaghetti-code indicates that you have not planned this project before attempting to code it.

It drives me nuts to see "programmers" jump into code without a plan! The plan MUST be developed in terms of the process! Otherwise, as you have now, you end-up with useless spaghetti-code.

Designing-on-the-fly is Just Plain STUPID! (<<-- BTW, that word fits nicely into the blank at the top of this post).

Caveat:
Everything I've said is TRUE... for the situation as you have described it.

If the situation is not exactly as you have described... well...
 
Wow, my 1st butt chewing here (maybe deservingly so, maybe not).
I see that I definetly need to clarify. This alarm sequence is not for a machine. We have a setup where each line on the assembly floor has a switch at the end of it. If an operator deems they need maintenance personnel they turn it on which runs into an A0J2 plc then turns on a buzzer for 5 seconds and turns on a light to alert maintenance of which line is down.
Management now wants to be able to stick there head in there and see which lines has been down longest. That's it. No chance to damage machines or operators. I feel a better way would be to install an HMI and record the actual time, but that is not my decision to make.

The very fact that you have spaghetti-code indicates that you have not planned this project before attempting to code it.

Well although not a good excuse I'm not a programmer I'm an electrical maintenance tech who sometimes does programming. I've tried to write it out on paper and couldn't make sense of it. That's the reason I have been writing the code on a test plc (So I would have something that resembled a plan when I did the actual job).

Hope this clears it up some.
 
Alarm sequence

What Terry, or any other person here who really knows what they are talking about, is saying is, you have to understand the problem before you attempt a solution. Also, trying to explain to strangers about your particular surroundings is very difficult. The best help on this site will come when you have presented your situation clearly. Also, telling anyone you have spaghetti-code is inviting ridicule. So, do some homework. Check out what is really required. Check with some of your fellow workers and operators to see what they think. Develop a plan of attack. If you are lacking in programming experience, then you can get some help with that here. But, only for particular things that are well explained. Generalities always invite over compensation and supposition, not to mention criticism! Come back and ask some different and more direct questions and you will be surprised how much good help you get.
 
Also, trying to explain to strangers about your particular surroundings is very difficult.

Well maybe that's my problem.

Basically all I need to know is there a function in a fx or a series plc that will record the inputs in order of time they were set regardless of the order? The rest I can easily handle.

I have tried this with the sftl instruction, but that doesn't seem to work. I have had some success with Incrementing and decrementing data registors. It just uses a lot of code.
Also, telling anyone you have spaghetti-code is inviting ridicule.

Well I wouldn't call the code I've wrote spaghetti code I just used it as a joke since that word is thrown around so much (I didn't realize it would invite so much fury, lighten up).

Anyway I hope this is a little more straight forward. I hope Terry finds time to respond (Even though he fired on me I've learned alot from his posts)
 
I'm not familiar with that plc. Does it have a time clock? if not you could build one then when an alarm(or is that maintanance request) is triggered then log the time and line into integer files. At that point simple compares can be used to set bits for the which ones flash and which stay on.


Drewcrew6
 
FIFO, not bit shift

tlvaun:

You can't use a bit shift, because a bit does not contain enough information to do what you are trying to do.

If I'm reading your original post correctly, I think your using the idea of a bit shift put Terry on the wrong track. Looking at his response, it seems that He's trying to have a series of alarm lights follow the process (which is where you normally use a bit shift). What I'm picturing is a big machine with 20 light bulbs all over it. If a particular area has a problem, the light bulb there goes on. From a distance, you can tell where the problems are. And just to make it even easier, you want to blink the two newest problem spots, just to help catch the eye.

Peter has the right idea. Use a FIFO and stack the alarms.

I don't know the Mitsu instruction set, so your going to have to figure out the exact mechanics of how to implement the following, but this should do what you are asking to happen. Re-read Terry's reply carefully as to whether what you are asking for is what you want.

Break the task into two parts - detecting the alarm, and lighting the light bulbs.

Alarm Logic:

When alarm conditions are true:
1) Set a bit for "Alarm Condition 'x' is active"
2) On a one-shot, move the value 'x' in the FIFO input register.
3) On the same oneshot, trigger the FIFO to load the 'x' into the stack.

You cannot wait until you've process all the alarms to perform the FIFO load. If you have two alarms in the same scan, the first one will be overwritten by the second.


Alarm Light Logic:

For each alarm light, examine the first and second positions in the FIFO stack, like in the following code:

Alarm 1 Alarm 1
is active Light
---| |--+--| FIFO_1 <> 1 |-----| FIFO_2 <> 1 |---+------( )
| |
| Blinker |
+--| FIFO_1 = 1 |-----+-------| |--------+
| |
+--| FIFO_2 = 1 |-----+



.
The above should only take, at most, three rungs of logic for each alarm - one for the condition, one for the one-shot FIFO load, and one for the light. 20 alarms = 60 rungs. If you've 84 rungs for 5 alarms, you DO have spagetti code, despite your protests.

<hr>

Just re-read Peters post. The above logic doesn't take care of one case, and this again goes back to what Terry was saying abot logical design. If the second alarm in the stack is cleared, but the third one is not, do you want the third one blink?

If so, you'll have to add a rung of logic that checks to see if the condition corresponding to the number in the stack is active. If not, the stack must move up by one. You would have a similar rung checking the second number in the stack. You would also have to set up the stack such that when you do these removals, a 'zero' will be loaded at the bottom of the stack, and can evenutally work it's way up to the top if all the alarms are cleared.

You DON'T have to do as Peter suggested and remove alarms from anywhere in the stack. If an alarm drops out, it's number can remain in the stack until it either gets pushed out the bottom by lots of new alarms, or removed when it gets pulled to the top by alarms dropping out.
 
Last edited:
PART-1

First...
There was no "butt-chewing" anywhere in my first posting. I wrote simple, straight-forward, statements relative to the conditions you described.

There was nothing in what I said that you should take as an attack on you. No attack was made, none was intended.
(Maybe some should lighten-Up... Maybe some should thicken-Up - As in skin)

This is another loooooonng posting. I know it will require PART-1 and PART-2. Because this went so long, I left off after giving "THE PLAN". I still need to develop a simple means of implementation. I think this can be worked so as to bring all status current in a single scan. Meanwhile, chew on this for a while.

Now, with respect to your latest mission statement... (I still don't know if it is accurate, but, here's my best shot)

From your second posting...
Management now wants to be able to stick there head in there and see which lines has been down longest.

  1. Running lines do not show a Red Light.
  2. Downed-lines are indicated by a Red Light (flashing or not)
  3. Management wants to know which line(s) was/were down the longest.
  4. The line(s) with the longest down-time is/are indicated by a FLASHING Red Light.
    [/list=1]

    I should (and do) think that the idea is to minimize the down-time associated with any given line. I can imagine that there are complaints that "I called for service first, but received it last! It's making my down-time worse than it should be!"

    For example, if Line-6 has been down for 15-minutes and Line-3 has been down for 2-minutes, maintenance should service Line-6 first, then, Line-3. Otherwise, if Line-3 is serviced first, then Line-6 will absorb all of the service-time on Line-3 as Line-6 down-time.

    Now, citing the example I just described, if three lines are down...
    Line-6 down for 15-min,
    Line-3 down for 2-min, and
    Line-5 just went down

    According to the specified scheme, Line-6 and Line-3 will have a Flashing Red Light. Line-5 will have a Solid Red Light.

    When maintenance comes in to service the downed-lines, they see two Flashing Red Lights. Which line should maintenance service?

    If they service Line-6 first, then they have guessed correctly. If they service Line-3 first, then they have guessed incorrectly. Line-6 will absorb all of the Line-3 service-time as Line-6 down-time.

    Is there a way to prevent this problem from happening? Yes, there is, with this scheme...
    1. Running lines do not show a Red Light.
    2. Downed-lines are indicated by a Red Light (flashing or not)
    3. Management wants to know which line (single line) has been down the longest.
    4. The line (single line) with the longest down-time is indicated by a FLASHING Red Light.
    5. Maintenance needs to service the line with the longest down-time FIRST.
    6. Maintenance then needs to be able to identify the next longest down-time and service it. Repeating the exercise until all lines are up and running.
      [/list=1]

      When maintenance arrives and sees one Flashing Red Light and several Solid Red Lights, maintenance KNOWS that the line with the Flashing Red Light has been down the longest.

      (I really don't see any advantage in displaying more than one Flashing Red Light. If you have four lines down, what do you gain by having an indication that two of those lines were down longer than the other two -- That information is OBVIOUS without the additional Flashing Red Light! However, if management really needs to see two Flashing Red Lights, well, that can be easily arranged. However, be aware, it will be counter-productive!)

      So... Upon arrival at the line, maintenance presses the "ACK" button for the particular line. The Flashing Red Light for that line goes OFF. At the same moment, the Red Light associated with the line that has the next longest down-time changes from Solid Red to Flashing Red.

      That way, it becomes immediately apparent which line needs to be serviced next. And, if there are several service guys on-hand, then the next service guy can tackle the next line, and so on, for as many service guys as are available.

      The sequence of events that I have described fit well within the concept of a "FIFO-Service-Que".

      Now, if this game is played "According to Hoyle", you would always be playing in a "First-In / First-Out" manner.

      Here's the rub...
      There is nothing to prevent a service guy from servicing a Solid Red Light instead of handling the Flashing Red Light.

      So... How do you build a Service Que? And how do you build one that can handle the out-of-order case I just described?

      I'm not familiar with the PLC you are talking about and what functions it might have. So, I'm going to suggest a design that should play on any mid-level PLC.

      THE PLAYERS:
      • Q-NUM<sub>NEXT</sub>
      • Q-NUM<sub>ADJUST</sub>
      • Q-NUM<sub>WORD-1</sub>
      • Q-NUM<sub>WORD-2</sub>
      • Q-NUM<sub>WORD-3</sub>
      • Q-NUM<sub>WORD-4</sub>
      • ---
      • ---
      • ---
      • Q-NUM<sub>WORD-20</sub>
      PLAYER DESCRIPTIONS:
      • Q-NUM<sub>NEXT</sub> is the Next Available QUE-Number
      • Q-NUM<sub>ADJUST</sub> is a value that is used to Adjust the remaining Priority Values as Line-Alarms are removed from the QUE.
      • Q-NUM<sub>WORD-X</sub> Word-X is a 16-bit V-Mem Location associated with a particular Line; Word-1 = Line-1, Word-2 = Line-2, etc. The range of values allowed in Word-X is 0 (zero) to 20. Zero represents NO ALARM. The values 1 to 20 represent Que-Position, where 1 = Highest Priority and 20 = Lowest Priority.

      THE RULES:

      At PLC Start-Up (power-on)...
      • All Q-NUM<sub>WORD-X</sub> values are set to "0" (zero).
      • Q-NUM<sub>ADJUST</sub> is set to "0" (zero).
      • Q-NUM<sub>NEXT</sub> is set to "1"
      At this point, there are no Red Lights, flashing or otherwise.

      Loading Q-Nums:

      The program then begins "watching" for an Alarm Input to GO ON (Transition from OFF to ON). If, after start-up, an operator sees that his alarm switch is ON but there is no Red Light, then cycling the switch will activate the light.

      When the program "sees" an Alarm Input go on, the program copies the current value of Q-NUM<sub>NEXT</sub> into the V-Mem location associated with the particular line. For example, if Line-3 Alarm goes ON, then the current value of Q-NUM<sub>NEXT</sub> is copied into Q-NUM<sub>WORD-3</sub>. In this case, Q-NUM<sub>WORD-3</sub> goes from "0" to "1".

      The Q-NUM<sub>NEXT</sub> value is then Incremented by one to "2".

      If Line-7 Alarm goes ON, then the current value of Q-NUM<sub>NEXT</sub> is copied into Q-NUM<sub>WORD-7</sub>. In this case, Q-NUM<sub>WORD-7</sub> goes from "0" to "2".

      The Q-NUM<sub>NEXT</sub> value is then Incremented by one to "3".


      Unloading Q-Nums:

      This will handle "normal" FIFO activity as well as the "out-of-order" situation.

      When maintenance arrives at a downed-line, the first task is to "ACK" the Alarm. He does this by turning the Alarm OFF. When the program "sees" an Alarm Input go OFF (Transition from ON to OFF), the program "grabs" a copy of the value in the V-Mem location associated with that particular line. For example, if the Alarm Input associated with Line-9 goes OFF, then the value in Q-NUM<sub>WORD-9</sub> is copied into Q-NUM<sub>ADJUST</sub>. If Line-9 has a Priority Value of "6", then "6" is copied into Q-NUM<sub>ADJUST</sub>; Q-NUM<sub>ADJUST</sub> goes from "0" to "6". The value in Q-NUM<sub>WORD-9</sub> is set to "0" (zero).

      At that point, the program goes through each of the Q-NUM<sub>WORD-X</sub> locations and examines the current values. If the current value is "Greater Than" Q-NUM<sub>ADJUST</sub>, then the value at that location is Decremented by one.

      For example, let's assume that 9 lines are down and that the service guy chose to service "out-of-order" (servicing Priority-6 instead of Priority-1). All priorities greater than "6" are decremented; the line with Priority-7 becomes Priority-6, the line with Priority-8 becomes Priority-7, and, the line with Priority-9 becomes Priority-8.

      If the maintenance guy serviced the line with Priority-1, then again, the value in that particular Q-NUM<sub>WORD-X</sub> is copied to Q-NUM<sub>ADJUST</sub>, the value in that particular Q-NUM<sub>WORD-X</sub> is then set to "0" (zero). At that point, the program, again goes through each of the Q-NUM<sub>WORD-X</sub> locations and examines the current values. If the current value is "Greater Than" Q-NUM<sub>ADJUST</sub>, then the value at that location is Decremented by one. Since Q-NUM<sub>ADJUST</sub> is equal to "1", then all remaining lines in the QUE (with priorities "Greater Than 1") are decremented and therefore, bumped-up in the QUE.

      So.... That's the PLAN! This ought to be enough to get you into some real trouble! I'll discuss Output Control, Output Ladder and potential problems in PART-2
 
PART-2

Controlling Alarm Light Outputs

The Output to Line-X Red Light is controlled by the value of the associated Q-NUM<sub>WORD-X</sub>.

Using my scheme, where only the highest priority is Flashing...
  • If the value of the word is "Greater Than 1" then the Light is ON Solid.
  • If the value of the word is "1" then the Light is Flashing.
  • If the value of the word is "0" (zero) then the Light is OFF.

Using the management scheme, where the TWO highest priorities are Flashing...
  • If the value of the word is "Greater Than 2" then the Light is ON Solid.
  • If the value of the word is "2" then the Light is Flashing.
  • If the value of the word is "1" then the Light is Flashing.
  • If the value of the word is "0" (zero) then the Light is OFF.



Ladder Code for Actual Output Control

Using my scheme, where only the highest priority is Flashing...


.5-Sec
Q-NUM<sub>WORD-X</sub> +1 Flash-Bit Output to
-----------| = |-----------| |------------+-------( ) Line-X Red Light
|
|
Q-NUM<sub>WORD-X</sub> +1 |
-----------| > |-----------------------------+



.

Using the management scheme, where the TWO highest priorities are Flashing...


.5-Sec
Q-NUM<sub>WORD-X</sub> +1 Flash-Bit Output to
-----------| = |--------+-------| |------+------( ) Line-X Red Light
. | |
. | |
. | |
Q-NUM<sub>WORD-X</sub> +2 | |
-----------| = |--------+ |
. |
. |
. |
. |
Q-NUM<sub>WORD-X</sub> +2 |
-----------| > |----------------------------+



.

POTENTIAL PROBLEMS:
The first thing that occurs to me is that there is still the possibility of more than one input changing state on a given scan. This too can be handled on a relative-basis. That is, an arrangement can be made where all changed states are logged at a single time. This becomes a QUE-for-the-QUE. Since, in this case, more than one Line-Status has changed, it doesn't matter which gets added or removed from the QUE first -- as long as ALL are accounted for.

So, when the program sees that changes have occurred, it first logs the change as an ADD or a REMOVE. You can use another set of V-Mem words associated with each line. The value in those words range from 0 to 2. Where 0 = No Action, 1 = ADD, and 2 = REMOVE.

Alternatively, you could use the existing set of V-Mem words. This could be a bit messy if you don't choose a good way to meld the Priority and ADD/REMOVE Status in the single word. Since you are tracking only 20 lines, you only need to use the 5 lower bits in any word. You could then use Bit-6 for ADD and Bit-7 for REMOVE.

If you find that you need to ADD a particular Line-Word to the QUE, then you only need to write-in the current Q-NUM<sub>NEXT</sub> value into that word. Bit-6 will be automatically RESET to "0".

If you find that you need to REMOVE a particular Line-Word from the QUE, then you only need to write-in a "0". Bit-7 will be automatically RESET to "0".

When you REMOVE a particular Line-Word from the QUE, all of the other currently QUE'ed Line-Words need to be decremented. This requires that you "grab" the current ADD/REMOVE status (using a MASK), save it, then perform the ADJUST on the Line-Word, then AND the result with the saved ADD/REMOVE status.

The priority for the ADD/REMOVE servicing is determined by V-Mem order. Line-1 is always checked first while Line-20 is always checked last. In the worst case, it might take several scans to bring everything up to date. The time difference in insignificant.

There are, no doubt, issues I haven't covered or seen... there always are!


Jeezzz.... enough already!
 
I had a similar issue with a line of machines, they wanted tabs on alarms and downtime etc.

I bought Vorne displays that could show RPM, production rates etc BUT would show downtime and alert the team leader via computer to the fact the machine/line was down. The displays automatically return to primary function when machine starts up again but the downtime numbers are retained so management can keep track.

This was one of those maintenance isnt doing its job type thing and they originally wanted flashing lights but this was actually cheaper to implement and kept better records. In fact it kept records so well that production stopped using the displays. wonder if it had anything to do with the fact that maintenance was only responsible for less than 5% of the downtime?
 
Would some one turn that damn alarm off?

Allen Nelson said:
tlvaun:
You DON'T have to do as Peter suggested and remove alarms from anywhere in the stack. If an alarm drops out, it's number can remain in the stack until it either gets pushed out the bottom by lots of new alarms, or removed when it gets pulled to the top by alarms dropping out.

The error should be cleared in some way. What happens if the cleared alarm is not followed by other errors to push it out the bottom?

I also cringe at the ladder above. It would take a lot of ladder to do this using coils. One should use whole registers using XOR, OR, and ANDN ( and not ) instructions.
 
Peter said...
<hr size="1" color="#000000" align="center" width="100%">I also cringe at the ladder above. It would take a lot of ladder to do this using coils. One should use whole registers using XOR, OR, and ANDN ( and not ) instructions.<hr size="1" color="#000000" align="center" width="100%">

Yes, Peter. It would take a lot of ladder. I used the method indicated because tlvaun said...
<hr size="1" color="#000000" align="center" width="100%">Well although not a good excuse I'm not a programmer I'm an electrical maintenance tech who sometimes does programming.<hr size="1" color="#000000" align="center" width="100%">

And then Terry said...
<hr size="1" color="#000000" align="center" width="100%">I'm not familiar with the PLC you are talking about and what functions it might have. So, I'm going to suggest a design that should play on any mid-level PLC.<hr size="1" color="#000000" align="center" width="100%">


My purpose is threefold...
  • Layout "THE PLAN" in such a way as to teach Structured thinking.
  • Keep the code Above Board (Use methods that do not hide activity from the programmer)
  • Make the code Generic (Use functions that are common to most, if not all, PLC's)

Peter,
There certainly are ways to handle all of this stuff at the bit-level, behind-the-scenes, using pointers, indirect addressing, and then mapping the results to the outputs. That's pretty high-level stuff for "...an electrical maintenance tech who sometimes does programming."

My response is tailored to the questioner... maybe. It might very well still be above his head, but I think this is as simple (from a novice point of view) as it can be made. (It may yet be the case that I still don't have an understanding of the problem! - It could happen! It often does.)

And besides, as I said in my first posting, I do find this to be an interesting exercise. It illustrates, clearly, how a concept, which is percieved to be simple and straight-forward, might not be as simple and straight-forward as one thinks (tell me how you tie your shoes).

And, just for the hell of it, I'm gonna look at the problem again using the methods you suggested. I wonder how small this code can be made.
 
So, tlvaun....

Do I have a reasonable understanding of your situation?

Did everything make sense to you?

What's happenin'?

...waitin' on you.
 
Sorry late on reply (work many hours in maintenance ya know)

Peter,

I found the FIFO commands in the manual, but they were only available for the higher end models. I plan on getting one at work and trying it.

I believe I have been able to get it to work through Terry's method if I understood him correctly. When an input is on I incremented a data registor by 1 every time another was turned on, decremented by 1 everytime another input was turned off, and reset it when that input was turned off. Then done a compare statement to decide my conditions.
The only problem I've encountered is as Terry suggested when I flip two switches at the same time (same scan) it gets it out of sequence. I will get a chance later to play with it and see if I can get around this. Luckily I have awhile before I have to do the project. I'll post again if I run into a roadblock. Thanks to all that replied.
 

Similar Topics

Hello all, What I want to do is take a word of data and move the bits over 1 bit. So to keep it simple: 0001 0011 1100 0110 and move into...
Replies
2
Views
1,507
Hi, I need to bit-shift a block of words in an Omron PLC by a certain amount. Is SFTR the only way to do this? I've tried NSFR/NSFL but from...
Replies
11
Views
3,657
I am looking for an instruction similar to the RS Logix BTD instruction. I need to be able to strip bits in the middle of a 32 bit double word...
Replies
1
Views
1,888
Getting closer to understanding BSR/BSL but I still cannot understand the "CONTROL" address function. I am using R6:10 and I can see the 0's amd...
Replies
2
Views
1,929
hi there guys i know this will be easy for you as a newbie here could someone explain the operation of the (AB) bit shift left and bit shift...
Replies
7
Views
7,192
Back
Top Bottom