Loops vs Program/stage

[CReese]

What I don't understand is that it was working fine and I changed it to MAKE it yield, as opposed to vice-versa. Stopped it and brought it back to term and can read/write, but no looping is happening.

What's the easiest way to see what's eating up the scan time?

[CReese]

and we're back...

[BobO]

What's the easiest way to see what's eating up the scan time?

Great question...a utility that doesn't exist yet.

[franji1]

   if Diff(AlarmStatus[AlarmIndex])
       run LogEvent

1. LogEvent will not run until after the loop has yielded, possibly on the next scan if LogEvent code-block is before your loop code-block.
2. Differentials and Arrays do not mix.  The differential contact only saves the ON/OFF state from the previous time it executed, so if AlarmIndex is 7, you are not "differentiating" AS7 vs. the previous I/O scan's AS7, but AS6 state compared to AS7's state (assuming the index went from 6 to 7).
3. Say your loop finds 3 alarms that changed state within one time slice, do you expect LogEvent to run 3 times, or just once?  Remember, RUN is NOT CALL.

[BobO]

Another key point...Tasks and Programs are not subroutines, and are not run in context. We will be adding functions and subroutines in a future version, the technology is already in the controller and is proven, it's just lacking the UI needed to create and manage.

[CReese]

3. Say your loop finds 3 alarms that changed state within one time slice, do you expect LogEvent to run 3 times, or just once?  Remember, RUN is NOT CALL.

This is a very good question. I see that as I have it programmed, it will only handle the last event, as it throws the Log Message that is created into a temporary variable. I suppose the way to do this better is to create a message queue and then have the logger process the queue.

Or, as I proposed previously, change this into a staged program that runs one array item per scan.

Or, can I just have it exit the loop on LogEvent and resume the program on the next scan? This way it is guaranteed to only have to process one event. It has the added bonus of logging the event as quickly as possible without finishing the loop.

[CReese]

Yes, so how about just adding 'exit' after 'LogEvent'? Will this resume the loop where it left off? Even if not, it's an easy way to avoid the possibility of not handling an event.

[franji1]

Or, can I just have it exit the loop on LogEvent and resume the program on the next scan? This way it is guaranteed to only have to process one event. It has the added bonus of logging the event as quickly as possible without finishing the loop.

I honestly think you need to eliminate all LOOPs and use the natural scan of the PLC as your "loop", but using events to
1. Increment the processing index
2. Log the event

Make all of this event driven.  I would stick this all in a stage program code block.  Since this is probably something that you want to do all the time, I would only have $Main kick it off "RUN MonitorAlarms" and MonitorAlarms intializes itself in its first SG (say SG0, hence you never JMP back to SG0), and it auto-resets the index whenever it reaches the end

SG S0 Initialize (set index to 0, etc.)
SG S1 See if alarm state @index has changed (you will need a duplicate array of alarm bits to save previous alarm state); if it has, jmp to S2, otherwise jmp to S3
SG S2 Log Alarm Event, once that is done, jmp to S3
SG S3 Put current alarm state (Alarm[index] into PrevAlarm[index]
   Increment index; if index exceeds length, reset index to 0, unconditionally JMP to S1 (NOT S0)

This will minimize scan time.

What are you doing to "Log Alarm Event"?  Sending an EMAIL?  That can take seconds per alarm.  If you have no alarms, this will take N scans where N is the number of alarms.  If N is 100, with a 1ms scan time, that's 100ms "calendar time".  But if "Log Alarm Event" takes 3 seconds, and all alarms turn ON, that will take 300 seconds (5 minutes) of "calendar time" to process all 100 alarms.

[CReese]

Or, can I just have it exit the loop on LogEvent and resume the program on the next scan? This way it is guaranteed to only have to process one event. It has the added bonus of logging the event as quickly as possible without finishing the loop.

I honestly think you need to eliminate all LOOPs and use the natural scan of the PLC as your "loop", but using events to
1. Increment the processing index
2. Log the event

This is possible, and I may end up doing it. I just don't think it is necessary.

SG S1 See if alarm state @index has changed (you will need a duplicate array of alarm bits to save previous alarm state); if it has, jmp to S2, otherwise jmp to S3

I've got this handled without a duplicate array, and it would be more. We log on many different event changes, so I don't want duplicates of everything

What are you doing to "Log Alarm Event"?  Sending an EMAIL?  That can take seconds per alarm.  If you have no alarms, this will take N scans where N is the number of alarms.  If N is 100, with a 1ms scan time, that's 100ms "calendar time".  But if "Log Alarm Event" takes 3 seconds, and all alarms turn ON, that will take 300 seconds (5 minutes) of "calendar time" to process all 100 alarms.

I create a string based on the type of the event, alarm name, and current time. I mash them into a string and process them through a FIFO Alarm Log in the MIR registers for read by other network devices, such as screens and our datalogging server that sends the data across the intertubes. I've about filled the memory of the DoMore, but I keep about 100 events logged at 40 characters per message, if I remember correctly.

[BobO]

Yes, so how about just adding 'exit' after 'LogEvent'? Will this resume the loop where it left off? Even if not, it's an easy way to avoid the possibility of not handling an event.

Please pay close attention to what Mark just described. To answer the question, no, EXIT terminates the program completely...a YIELD would kick out for one scan and let something else run. Fine if your logging will take no more than one scan...but...as Mark suggested, make it more event-centric and eliminate the time dependence. More work, but guaranteed to work all the time...anywhere.

[BobO]

This is possible, and I may end up doing it. I just don't think it is necessary.

You would still use a logical loop, just not a looping instruction. By creating the loop in stages, and making the sequencing event based, you solve a multitude of headaches that you may not have had yet. Trust us on this one.

[CReese]

I refactored it, and it's noticeably slower. Is there an obvious reason I cannot get a timer to work properly in my staged process?

I have a timer reset in stage 0, and I only return to stage 0 when my index needs to be reset. The rest of the times it goes back to stage 1. The timer never starts running.

[BobO]

Timers aren't standalone hardware entities that run independent of the PLC scan, they are software functions performed by the timer instruction. If a timer instruction is not being invoked, it doesn't accumulate time. If you are timing a stage, put the TMR in that stage. If you are timing globally, put the TMR in something that is constantly being executed...perhaps before the first stage of the program block.

[CReese]

This works fine, but now I can't seem to get it to reset. Is it not possible to reset the timer from a single stage to see how often it reaches that stage?

[BobO]

RSTT