Sequential Status Display...

Greg:

I like that. Much cleaner than mine. Let me see if I'm undertanding you:
Each alarm has a register (in a contiguous array) that is either
"Zero" or "Message Number". Your 'message handler' searches through
the array (by incrementing a pointer once per scan). If it finds a
non-zero number, the pointer dwells at that register for a timer, and
then resumes searching.

Translating it into AB, for cousin Eric (not that he needs it -
I just enjoy doing this ladder stuff):


LANE 1
IS LOW +--- MOV -+
----+----| |-------| 1 |
| | N7:51 |
| LANE 1 +---------+
| IS LOW +--- MOV -+
+----|/|----- | 0 |
| N7:51 |
+---------+

LANE 2
IS LOW +--- MOV -+
----+----| |-------| 2 |
| | N7:52 |
| LANE 2 +---------+
| IS LOW +--- MOV -+
+----|/|----- | 0 |
| N7:52 |
+---------+

Duplicated 2 more times, for N7:53 & :54

STILL USING INDEXED ADDRESSING BECAUSE MICROLOGIX 1000 DOESN'T SUPPORT INDIRECT

+--- MOV -+
------| N60:0 |
| S:24 |
+---------+


MOVE THE POINTED TO REGISTER INTO THE MESSAGE REGISTER (N7:50)

CURRENT
MESSAGE
+--- NEQ -+ +--- MOV -+
---| #N7:50 |-------| #N7:50 |
| 0 | | N7:50 |
+---------+ +---------+


MESSAGE TIMER. NOTE THAT THE INDIRECT MESSAGE IS CHECKED.

MESSAGE
TIMER
+--- NEQ -+ T4:10/DN +--- TON -+
---| #N7:50 |------|/|------| T4:10 |
| 0 | | 5 SEC |
+---------+ +---------+


INCREMENT THE POINTER

CURRENT
MESSAGE POINTER
+--- EQU -| +---- ADD -+
---+---| #N7:50 |---+---| N7:60 |
| | 0 | | | 1 |
| +---------+ | | N7:60 |
| | +----------+
| MESSAGE TIMER |
| T4:10/DN |
+------| |--------+



WHEN THE POINTER GETS TO THE END, RESET IT

POINTER POINTER
+--- GEQ -| +---- MOV -+
----| N7:60 |-----| 1 |
| 0 | | N7:60 |
+---------+ +----------+


IF THERE ARE NO ERROR, CLEAR THE MESSAGE

LANE 1 LANE 2 LANE 3 LANE 4
IS LOW IS LOW IS LOW IS LOW +--- MOV -+
---|/|-----|/|-----|/|-----|/|-----| 0 |
| N7:50 |
+---------+



That last line I found I needed to add when I went to test the code.
You could clear the message on some other event (like timer done),
but then you get a 'blip' between message. If the LOW bits are
contiguous, that line can be simplified.

I also noticed a typo in my orginial code. The bits on the last rung
which check to see if the alarm is no longer valid should be -|/|-,
not -| |-.
 
Whoa Allen, what were you smokin' when you wrote that? :eek: And who's "Greg"? :confused: :D

You say "Using indexed addressing because the ML doesn't support indirect addressing"... It's the other way around. And then you USED indirect addressing :rolleyes: :D

And N60:0 ??? Where did THAT come from? :D

No, really, you're explanation made perfect sense to me. I'm glad you understood glaverty's post (Is THIS the "Greg" you're referring to?). I was completely lost after reading it. utoh

For those who don't know...

Though you can't use indexed addressing (i.e. #N7:50) with the ML1200 and 1500, you CAN use a register (let's use N7:50) to point to an offset (indirect addressing). For the value, you use brackets "[]" around the register containing the offset value.
So, if the value of N7:50 is 41, and you use N7:[N7:50], this actually points to N7:41. Confused yet? It's kinda simple once you figure it out...

Below is a modified version of Allen's code to reflect what I finally got to work:

(Note to Phil... Can you make the "LADDER" code automatically bump up the HTML [size] value to "3" for easier viewing?)

LANE 1
IS LOW +--- MOV -+
----+----| |-------| 1 |
| | N7:51 |
| LANE 1 +---------+
| IS LOW +--- MOV -+
+----|/|-------| 0 |
| N7:51 |
+---------+

LANE 2
IS LOW +--- MOV -+
----+----| |-------| 2 |
| | N7:52 |
| LANE 2 +---------+
| IS LOW +--- MOV -+
+----|/|-------| 0 |
| N7:52 |
+---------+

LANE 3
IS LOW +--- MOV -+
----+----| |-------| 3 |
| | N7:52 |
| LANE 3 +---------+
| IS LOW +--- MOV -+
+----|/|-------| 0 |
| N7:52 |
+---------+

MOVE THE POINTED TO REGISTER INTO THE MESSAGE REGISTER (N7:40)

CURRENT
MESSAGE
+--- NEQ -----+ +--- MOV ------+
---| N7:[N7:50] |-------| N7:[N7:50] |
| 0 | | N7:40 |
+-------------+ +--------------+


MESSAGE TIMER. NOTE THAT THE INDEXED MESSAGE IS CHECKED.

MESSAGE
TIMER
+--- NEQ -----+ T4:10/DN +--- TON -+
---| N7:[N7:50] |------|/|------| T4:10 |
| 0 | | 5 SEC |
+-------------+ +---------+


INCREMENT THE POINTER

CURRENT
MESSAGE POINTER
+--- EQU -----| +---- ADD -+
---+---| N7:[N7:50] |---+---| N7:50 |
| | 0 | | | 1 |
| +-------------+ | | N7:50 |
| | +----------+
| MESSAGE TIMER |
| T4:10/DN |
+--------| |----------+



IF POINTER IS BELOW THE BEGINNING OF THE RANGE,
OR WHEN THE POINTER GETS TO THE END, RESET IT
TO THE BEGINNING OF THE RANGE (THIS ENSURES THAT
WE NEVER GO ABOVE OR BELOW THE RANGE OF 41 TO 45)


POINTER POINTER
+--- GEQ -+ +---- MOV -+
---+---| N7:50 |---+---| 41 |
| | 44 | | | N7:50 |
| +---------+ | +----------+
| |
| +--- LEQ -+ |
+---| N7:50 |---+
| 40 |
+---------+


IF THERE ARE NO ERRORS, CLEAR THE MESSAGE

LANE 1 LANE 2 LANE 3
IS LOW IS LOW IS LOW +--- MOV -+
---|/|-----|/|-----|/|-----| 0 |
| N7:40 |
+---------+




This is E-X-A-C-T-L-Y what I was looking for!!!! It works perfectly!:D

Many thanks to Allen and glaverty (er, Greg?) ;) for an elegant solution to a tricky problem. This is what PLCS.net is all about!

beerchug

-Eric
 
It's me

Eric, I am the Greg Allen was referring too.

Allen,

I'm not very familiar with AB code but from the looks of it you got it exactly. I didn't put the alarm registers in there but you figured them out exactly as they are written. I like this way of displaying alarms personally, the system this code is from only has 15 or so Alarms but there is no reason you couldn't have a lot more, your only limit would be the number of registers you have to work with. It's also nice because if you get multiple Alarm conditions you can see each one of them, not fix one just to have another come up. Though I find that if you fix one usually some of the other ones will go away too.

Anyways glad to have helped you Eric. Allen glad to have gotten you away from the boring paper work for a while.
 
What was I smoking when (Answer - nothing, but I had had two glasses of wine just before the last post)? My first attempt was an "off the top of my head". I'm not as good as Terry is with those.

Yes, it's Greg Laverty (got that from the old forum) who provided the

When I tried writing the ladder in RSLogix (just to prove it would work), I set the type to the lowest Micrologix 1000. I tried using indirect addressing (as your final solution did), but when I verified it, I got an error message "Indiect Addressing not supported for this data type (N)". I don't know those PLCs that well, so I assumed it couldn't and used indexed instead. (N60 was supposed to be N7:60 - I've got to find an easier way of converting RSLogix to ASCII - I used to be able to do it easily in AI, but I don't have it anymore) Glad your PLC supports indirect - it's cleaner.

I've reported the ladder problems to Phil already - different browsers do it differently, but it seems to have something to do with the width of the reply box.

Again, thanks for the diversion from writing Funcitonal and Design Specs.
 
The following is what I was thinking when I replied earlier. It approximates the action of the FBC instruction. To utilise this approach, you need to arrange your alarm or trigger bits contiguously.

For the code below, I have assumed that there are four bits to check in word B10:0 (bits 0-3) and their corresponding messages are numbered 1-4 with message 0 being blank. N7:0 selects the canned message. C5:0 preset determines number of bits to check. T4:0 determines message display time. B3/0 roughly corresponds to the 'found' bit of the FBC.

I don't have a ML1500 to test this on, so can't say whether or not this will work across word boundaries (i.e. for more than 16 bits).


rung 0
----+-+--CTU---+--+-
| | C5:0 | |
| | pre=3 | |
| +--------+ |
| |
+---+CLR---+--+
| N7:0 |
+------+

rung 1
B10:0[C5:0.ACC] T4:0.DN B3/0
---| |-------------|/|---+-----( )---+-
| |
| |
+-+--TON--+-+
| T4:0 |
| pre=2 |
+-------+

rung 2
B3/0
---| |----------------+---ADD-----+-
| C5:0.ACC |
| 1 |
| N7:0 |
+-----------+

rung 3
B3/0 C5:0.CU
---|/|-------------------(U)--

rung 4
C5:0.DN B3/0 C5:0
---| |-------|/|-----------(RES)--

 
Gerry, for my application, this might be an even MORE elegant solution! The things I need to sequentially display are bits, and the messages trigger directly from bits, so why bother manipulating words?... Great idea!

After reading more about indexed addressing, I learned one thing that I didn't know before... You can "nest" multiple pointers withing one address! This is scary when you think about how IMPOSSIBLE to understand you could make your code for some poor future programmer! :p Handy little thing, if you use it ONLY when needed....

Oh, and according to the manual, you can index across words... :cool:

Thanks,

-Eric
 
Multiple Alarms FIFO (Scrolling)

Hi Eric


I encountered a similar problem a few years ago when a client of mine wanted to display multiple alarm messages (blink-codes) on one indicator lamp.
It took me a while to find a solution. However what I came up with worked great, (for up to 15 alarms).

Here it goes.

1) Set aside one word for alarm bits and turn on a bit in the word as the alarm condition is present, up to 15 alarms.

2) Set aside another word, which will be your MASKING word.

3) Insert a bit in the making word and shift it left using the BSL instruction (AB). As the bit drops out (Word =0) insert the bit again so it is continuously scrolling through the word from right to left. You can even shift the bit every scan.

4) Now use a "Bitwise AND" to AND the two words together. This means that as soon as your "scrolling" bit in the Masking word is above the first error bit in your Alarm word, you will get a bit right under the two in your result word.

5) You have now captured your first alarm bit and all that is left is to use the "ENC" instruction (Encode 1 of 16 to 4) which will give you the bit number (position within the word) in BCD.

6) Use this BCD number to call the corresponding alarm to your display, and activate a timer that will pause the BSL instruction long enough for the message to be displayed on the screen. When the timer expires the scrolling bit (BSL) will take off until it hits another error bit above it. A new BCD number will be generated and a new alarm will be displayed etc. etc……….

Good luck,

Orn
 
You da man, Iceman! :cool:

Wow, can it get any simpler than this??? I have NEVER had a need to sequence more than 15 events... For 2, it's a piece of cake... I use this method:

TRACK 1 TRACK 2
OK OK
-----|/|---+---| |---+---(STATUS "TRACK 1 LOW")
| |
| CLOCK |
+---| |---+

TRACK 2 TRACK 1
OK OK
-----|/|---+---| |---+---(STATUS "TRACK 2 LOW")
| |
| CLOCK |
+---|/|---+



Actually, my second rung usually is just:

TRACK 2
OK
-----|/|-----------------(STATUS "TRACK 2 LOW")



because one bit will take precedence (you can't display 2 messages at once!) lolis

When you need 3 or more, there's no simple solution like this. :(

Many thanks!!!

-Eric
 
I am curious about certain things involved here. Please tell me if I am wrong here and why?

Most HMI have alarm pages that can be brought up based on your priority settings?

So if you created a Page that had nothing but (following the above scenario) a list of the Tracks couldnt you set the priority to bring this page up if any track was low. Example:

Tracks Low on Production
Code:
Track 1   LOW         
Track 2   OK          
Track 3   OK            
Track 4   OK            

   TRACK 1
     OK
-----|/|-----------------(STATUS "TRACK 1 LOW")
                   |
                   |-----(ALARM "TRACK LOW" PAGE)


This is basic but hopefully y'all understand what I am saying.

Doing this you would basically only need 4 rungs of code (for my example above)? Thats not counting the ladder needed to determine track is low naturally. This way they are sequenced and all shown at same time. LOW when low....OK when not LOW.

Tell me what is wrong with this concept please! I am certain there are some issues with type of hmi/display used but aside from that?
 
RS, as far as ALARMS are concerned, you are not wrong...

What we're discussing in this thread might be better thought of as "conditions" (for a lack of a better term). Basically just the current status of the machine. On the main HMI screen, I have a banner that displays this status. Things like "Full Automatic", "Finishing Cycle", "Running Single Cycle", etc., etc.... Just information for the operator.

This "Tracks Low" scenario is just another status. They are not alarms that need to be reset... These disappear as soon as the track(s) fill up with parts again. Let's say the machine is running in Automatic, but a track runs low on parts (i.e. the feeder bowl that fills this track has run empty). The machine will pause until the track fills up again, but then start running again automatically. If there is only one infeed track on the machine, you could just add this message to the banner. The operator sees this and attends to the problem (i.e. refills the feeder bowl with parts).

The problem is when there are multiple tracks. There are times when 2 or more tracks will run out of parts at (or nearly at) the same time. If you only display ONE of these messages, the operator will refill that feeder bowl, only to come back and realize that ANOTHER feeder bowl was also empty. Now they run off to refill THAT one. Upon returning to the HMI, they see that still ANOTHER feeder bowl is empty.

Now the operator is thinking:<blockquote>"I just walked past that feeder bowl on my way back to the HMI!... Why didn't you let me know that BEFORE?!?!"

"Now, before I walk ALL THE WAY to the back of the machine again, can you tell me how many OTHER feeder bowls are empty?!?!"</blockquote>If you frustrate the operators, there's a good chance they may take out this frustration on the machine! 🔨

By sequencing the messages, you can give the operator all the information they need B-E-F-O-R-E they head off! :cool:

-Eric
 
I asked this because I have created a scenario as I described. I have 5 machines with their own conveyors that each have their own Panelview(on a SLC 5/04/Devicenet system). The idea was to tell the operators via alarm/condition that their machine (each operator has to deal with 2 machines more or less) wasnt feeding. Each machine/conveyor must feed to another conveyor to combine the products for packaging.

I am not sure I understand the difference between conditions and a need for an alarm. I want ALL operators to KNOW what is happening when it happens and attempt to correct the situation. It may have been more eloguent to show the problem per station BUT I am not that good so looked for simple, and easy to understand. Was this simple feasible, and easy to understand?
 
OK, after re-reading your original question, I (think) I get it... At each machine, you automatically switch to your "Why is This Machine Not Running?" screen to let everyone know where the problem lies on the production line.

One question though... Let's say that a machine in "Group 1" stops. You display this at all other groups. When the problem is fixed, do you..

A.) Switch ALL displays back to "normal running" screen automatically?

or

B.) Require the operator at each other "group" to reset the alarm on their individual screens?

To elaborate on the "Alarm" vs. "Condition" topic...

I consider an "Alarm" to be something that, once it occurs, it MUST be "acknowledged" by the operator (i.e. Press the "Alarm Reset" button) before the machine will run again. Even if the "fault" happened to go away in the meantime. Examples of this would be low air pressure, a switch that didn't turn on/off when it should, etc...
By latching the alarm, it prevents intermittent things from being missed. If they didn't latch, you may never figure out why the machine "just stops once in a while" for what seems like no reason.

A "condition", "status", "event" (would someone please come up with a better term for this?), is something that will "automatically" reset (clear, go away, etc.) once the "condition", "status", "event" goes away. No operator intervention is required. Things like "Minimum Level Not Satisfied" on an infeed conveyor would cause the machine to stop (actually PAUSE), then begin running again once more parts are present on the conveyor. "Cycle on demand" is another term for this. If the first machine on a 10 machine process has a problem, you don't want to have to run around pressing "reset" on every other machine just because machine #1 stopped feeding the rest of the line, do you?

I'm sure we're probably both describing the same scenarios The confusion lies in trying to describe it accurately in words. :p

beerchug

-Eric
 
I got you...this is a condition. Once the problem is gone..ie conveyor/feed system is not low then it reverts back to main screen.

I have 5 machines (in one group) but they are maintained by 3 operators, therefore I need them all to know when any machine is not feeding or the conveyor is not full...the conveyors in this case act kind of like a hopper.

I think we are talking similar systems but I just used a different approach because of situation.
 
Sorry to dredge up an old thread like this, but Eric had asked over on the AutomationDirect.com forum for a look at what the code would be like to do this application.

I thought this would be a good time to dust off my rusty coding skills a bit. So with my handy dandy programmers reference, I took off into the wilds to see just how difficult it would be. Not quite as difficult as I first thought. 25 rungs to add/remove messages with a timed and scrolled display.

BTW, this is an advanced intermediate program IMHO. There are things in it that any programmer can add to their bag-o-tricks, so please take a look.

There are certainly other ways to do this. I wrote this specifically for the DL06 processor, although it would also work on a DL260 or DL450. I could have used one shots instead of the roundabout method that I chose, but I chose the way I did to show that there are always methods to accomplish almost anything given a bit of thought.

Feel free to comment. I have tested it and it seems to work well for me.
 
For those that need a bit more than what the Directsoft manual provides on how things work, here is a document that I wrote the other day that attempts to ease the transition to the Directlogic line. It explains indirect addressing a bit better than the manual I think.

As always, feel free to comment.
 

Similar Topics

Hi there, We have a system at a water treatment plant where large raw water tanks feed into the plant that's all on the same level. At high tank...
Replies
18
Views
3,768
Hi, I started off my career in PLC programming doing water/wastewater on AB around 20 years ago, but then moved overseas a few years later and...
Replies
57
Views
12,077
It appears to me that Logix is improperly executing sheets of an AOI in sequential scans instead of the same scan as the main program. To test...
Replies
4
Views
1,679
Hi, is it possible to read the name of the steps in an S7 Graph sequencer? In the parameterinterface there is, for example the parameter #S_NO...
Replies
21
Views
7,200
Hi All, is there a way to incorporate SFC with HMI in some way, in order to represent missing conditions for next step. Something similiar...
Replies
0
Views
974
Back
Top Bottom