Reply to Thread

Originally Posted by digo

Use the StatusDemux object from KitControl\Util

Link the "Out A", "Out B", and so on, each to the "In Boolean" slot of a Status StatusDemux object.

I personally don't like this setup because there's only a generic feedback slot, as opposed to individual status on your loads. Also, the elapsedActiveTime is making an assumption of runtime based on the commanded output, not the actual status of the load.

See if the image attached helps. I used separate BCOS alarm extensions on the pump alarm boolean writables. Typically I prefer to used the BooleanCommandFailureAlarmExt, as it has its own feedback slot so you can take care of the individual load alarms.

You sir are a genius! When I use the LeadLagRuntime I set the Max Runtime to something really high and unhide the RotateTimerExpired slot and link that to a TriggerSchedule so I do not h ave to rotate it based off of runtime but now I can rotate it based off of day and time.

Originally Posted by CountryBumpkin

I tried this as well with no success, I got the same results as you.

Use the StatusDemux object from KitControl\Util

Link the "Out A", "Out B", and so on, each to the "In Boolean" slot of a Status StatusDemux object.

I personally don't like this setup because there's only a generic feedback slot, as opposed to individual status on your loads. Also, the elapsedActiveTime is making an assumption of runtime based on the commanded output, not the actual status of the load.

See if the image attached helps. I used separate BCOS alarm extensions on the pump alarm boolean writables. Typically I prefer to used the BooleanCommandFailureAlarmExt, as it has its own feedback slot so you can take care of the individual load alarms.

Originally Posted by davem

Interestingly, there's a StatusAlarm extension available in the alarm palette, which could be dropped into each BooleanWritable used by the LeadLag's outputs...
However, when I tried it, the LeadLagRuntime block put the BooleanWritable into alarm, as previously described, but the StatusAlarm extension didn't throw an alarm, even when the appropriate status flags were set to generate an offnormal alarm...
It looks as though this particular extension is meant to do exactly as the OP requires, but for some reason it wasn't working on my test JACE. Perhaps it will work for someone else...

I tried this as well with no success, I got the same results as you.

Interestingly, there's a StatusAlarm extension available in the alarm palette, which could be dropped into each BooleanWritable used by the LeadLag's outputs...
However, when I tried it, the LeadLagRuntime block put the BooleanWritable into alarm, as previously described, but the StatusAlarm extension didn't throw an alarm, even when the appropriate status flags were set to generate an offnormal alarm...
It looks as though this particular extension is meant to do exactly as the OP requires, but for some reason it wasn't working on my test JACE. Perhaps it will work for someone else...

Originally Posted by CountryBumpkin

That is what I was saying in my last post, but there has to be a way to route them directly from the LeadLagRunTime instead of having to write all this program just as a work around.

Here's a similar thread from another forum:

Q:

I am using the lead/lag/runtime and I see that if the feedback for the controlled load doesn't come back in time, then that load reports "alarm" and the block enables the next load. Can I get this alarm into the alarm portal? I enabled the propagate flags "alarm" on the controlled load and it comes in red like it's in alarm already. How do I use the alarm function of the lead/lag block in my alarm service?

Use a BooleanCommandFailureAlarmExt from the alarm palette on your boolean writable points. If feedback and output values of the point are not equal for timeDelay duration, an offnormal alarm is generated.

I dropped the extension you mention onto my Boolean writables. I have read the, rather vague, help files and the users guide and I still am wondering how this works. Like you said "Alarm is generated if feedback and output values are not equal for the timeDelay duration". I have my boolean writables being staged on from a pid through the sequenceLinear object, How do I know how long the delay duration should be. If I'm understanding (fat chance) you and the manual correctly then the two values must be equal for the delayDuration or an alarm is sent. is this right? I am trying to generate an alarm if my load is commanded on and it doesn't operate. The alarm extension is titled like it will do what I want, but that delayDuration property is confusing me.

My understanding is that "Alarm is generated if feedback and output values are not equal AFTER the timeDelay duration". I think that's what Digo meant. This is usually the "fan startup delay time" to give the chance for a fan to build up pressure if you are using a differential air pressure switch. Typical time is 10 seconds or so unless it's a huge fan AND using a DPS...

...When you command the output on, if the status doesn't show up true within x amount of seconds, then the alarm is raised....
...You can use a statusdemux object linked to a boolean writable with a BCOSAlarm extension instead, where you can define the offnormal condition. The Status demux object would basically make the alarm output true when in alarm. There are check boxes for the status conditions you can demux...

That is what I was saying in my last post, but there has to be a way to route them directly from the LeadLagRunTime instead of having to write all this program just as a work around.

Since you have a latch object on the wiresheet now, how about tying its output to a BooleanWritable, under which you put a BooleanChangeofState alarm extension?

I found that there is a hidden slot called FeedbackTimerExpired and if I unhide that and tie the FeedbackTimerExpired slot to the 'Latch' of a BooleanLatch and tie the Feedback of the LeadLagRuntime to the 'In' slot of the Latch I can then use that to alarm... There has got to be a way to route these alarms though.

It alarms off of the feedback slot, If there is no feedback for a set amount of time it will alarm on the output that is supposed to be running.

I don't believe that this component has an alarm slot or any slots that would produce a fault, so there is no alarm functions to direct to an alarm class.

Kevin

Lead Lag Runtime In AX

I asked this question on niagara central but have not got an answer. So here is my question, When the Lead Lag Runtime point goes into alarm how do I tell it which alarm class too alarm to?