Indirect Addressing

[ASForrest 12]

Hi guys, I'm trying a new programming technique I haven't used before in RSLogix 5000, and my PLC is still 2 weeks away so I can't test a part of the logic. Just wondering if anyone can tell me how the following would behave. Essentially, this part of the application is a blower that blows product into one of 8 silos. Each silo has a valve on the top that when ON will divert into it's silo, and when OFF will pass through to the next. What I've done is created an add-on instruction called VALVE. I have then created an array of 9 VALVE's (9 rather than 8 because there's no Silo 0, so that's just a dummy). The valves tags are Infeed_Valve[0...9]. If I wanted to open the valve for Silo 5, I turn on Infeed_Valve[5].AutoOpen. The operator enters the number of the silo they wish to fill into the tag Destination, and I then use a tag in this manner: GRT Destination, 0, OTE Infeed_Valve[Destination].AutoOpen (if a destination other than zero is selected, activate the AutoOpen of that number's Infeed_Valve). At the end of that sequence, the destination will be reset to zero. My question is: will the AutoOpen for that valve be turned off? It was only a momentary bit, not a latching bit, so from one angle I think having removed that logic, the bit should be turned off. However, from another angle, I realise that I removed the OTE instruction referencing that particular valve while it was on, so with no logic to turn it off, it would probably stay on. Can anyone tell me which of the voices in my head is right? Thanks! :)

[b_carlton 61]

I have to assume that at some later point in the logic each Infeed_Valve[X].Auto_Open gets applied to a real world output. Early in the AOI, before the logic you show, Create an 'always_on' rung with eight OTU commands with the 8 Infeed_Valve[X].Auto_Open tags as arguments. So now they are all off and your selection rung will turn on only one. This won't 'pulse' an output assuming the first sentence above is true.

[ASForrest 12]

Your assumption is not quite right. The AOI reads the AutoOpen bit, processes other logic, and if conditions permit (e.g., in auto mode, process interlocks OK, not faulted...), writes to an output parameter qOpen. I think you might also slightly misunderstand how I've created the AOI (or else I misunderstand YOUR comment) - I've created an AOI called VALVE that controls only one valve, then defined Infeed_Valve with data type VALVE[9], so now I have an array of 9 of these VALVE's. These things being the case, I don't think your suggestion would work. However it probably would if it was the LAST rung - if the LAST rung of my AOI was always on "OTU AutoOpen", then it would process the AOI logic, then turn that bit off. If the external logic is still there to turn AutoOpen back on, the next scan of the AOI would be processed with it On. Once that external logic disappears, it will process one more scan with the AutoOpen bit On, and then the next scan it will have been turned off. In any case, thanks for the response, that gives me a good workaround if the bit DOES stay latched on. I'm still curious to know whether or not it actually WILL stay on or not though, if anyone knows or has a handy test bench set up ;)

[JRoss 84]

We'd have to see your actual program to give you a solid answer. I'm curious though. What happens if the operator selects a destination that is unavailable, so that the permissions don't allow the valve to open? Does the program automatically choose another silo, or is the a piping loop that allows the product to circulate until a valid destination is selected?

[ASForrest 12]

The Operator Interface doesn't allow the operator to select an invalid destination. In any case, the last silo in the line doesn't have a divert valve - if no valves are activated, it will end up in the last silo.

[drx 2]

Hi mate, Your second guess is right, wether you latch it or not has no effect, if the status of a bit is not re-evaluated, it just keeps the value it had at last evaluation. Say you are calling a routine doing such a thing : A:=B Then A will get the B value as long as you are calling that routine, if you stop calling it, A will stay at the value it was when you last went through the routine whatever B may be, until you call that routine again. Changing the instance / argument of an AddOn Instruction will have exactly the same effect, the previous instance/argument state will be freezed until it get re-calculated. If you need a "one-bit at a time" you don't have much choice but get sure to turn all the bits off but the one you need. I think it is what B_carlton suggested. You can consider changing your function's argument, send the whole array, have the "valve number" as an argument, and in your function you could memorize the previous/next valve to activate and deactivate one before you activate the other one, this would even allow you to manage the valve switching time, as when you open/close 2 valves at the same time, you have 2 valves ajar while state is changing. I don't know if you have much concern about that in your application, just to say. Good luck. Edited 24 Oct 2013 by drx

[ASForrest 12]

brilliant, thanks for that