LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

latch delay feed back?

Try the attached VI saved in LV8.0

RayR

 

Message 21 of 47
(1,565 Views)
Thanks Joe,

but the heater LED AND the External setting need to be on, so there would be some local variables, because you would have to write to it some stage and read it back another time?? Hm, not that easy...

Cheers,

Steffen.
0 Kudos
Message 22 of 47
(1,545 Views)
There's no need for any Local Variable.. 
 
What needs to be defined is the series of events..  The "what happens if / when... " scenarios.
 
Now I don't understand what you mean when you say the LED and the External control need to be ON. 
If you use a Local to force a change of state to the switch you'll be caught in a loop of who controls the heater.. 
 
You need to define the control hierarchy.   If the Front Panel switch the over-ride?  Which means no matter the state of the PLC (external switch), that the heater will follow what the Front Panel switch selects.  The way I configured it is that the switch will reset only on a change of state from the remote switch.
 
Can the program control the state of the external control?  I didn't think so, since it was not mentionned...
 
So back to the top of this post: 
 
Can you define the series of events?   The "what happens if / when... " scenarios.
 
RayR
 
EDIT:
Or did I completely misunderstand what the external switch is? 


Message Edited by JoeLabView on 06-19-2008 08:16 AM
Message 23 of 47
(1,529 Views)
Ray wrote "Can you define the series of events?   The "what happens if / when... " scenarios. ".
 
Ditto that!
 
Please put togethe a truth table of the inputs and outputs and I'm sure someonce can help you translate into code.
 
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 24 of 47
(1,525 Views)
Wow,
 
Reading through, those states seem kind of confusing!
Could you not put all the possible operations into a truth table?
 
FP | PLC | LED
0 | 0 | 0
0 | 1 | 1
 
etc etc..
Craig
 
EDIT : I really should read posts more carefully, Ben had already suggested a truth table 😉


Message Edited by craigc on 06-19-2008 07:54 AM

Message Edited by craigc on 06-19-2008 07:54 AM
LabVIEW 2012
Message 25 of 47
(1,522 Views)
Unfortunatley, I don't think a truth table will be enough..
 
Because you have two seperate controls trying to set their will to the heater.  So who wins?
 
You have an external control (PLC???) which can turn on or off the heater.
 
From what I could understand, you have a Front Panel switch that can be an over-ride as well as a control.  The Front Panel switch does not control the external switch, but can be affected by it.  Which kinda means the external switch has priority of control. 
 
But if the Front Panel switch can over-ride the external switch, then no matter what state the external switch is in, the heater should follow what the Front Panel switch decides...  But until when????  Until the next transition (change of state)?  For a given duration?  What would cause the external switch to "regain" control?  What would cause the Front Panel switch to loose control if it is simply an over-ride?
 
All of the above questions & more would not be covered in a truth table .. 😞
 
RayR
 
0 Kudos
Message 26 of 47
(1,531 Views)
"
Unfortunatley, I don't think a truth table will be enough..
"
 
It depends on the truth table. If those other factors influence the state, they should be included. Just add those other factors as additional collumns.
 
Truth tables are handy for defining these types of situations. They often reveal the extent of the complexity. I remember a customer suddenly realizing that his requirment meant that I should not only concider the current states of the system but also previous states.
 
Ben
 
PS 5-stars to Craig. If I thought is was good for me to post that idea, why wouldn't I think the same when someone else says it? Smiley Very Happy


Message Edited by Ben on 06-19-2008 08:14 AM
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 27 of 47
(1,526 Views)
Well said Ben,
 
What I was trying to say in my lenghty post is that we have to know all the constraints before determining a plan of action (solution, etc).  😉
 
Brain without cafeine is dysfunctional... 😞
0 Kudos
Message 28 of 47
(1,518 Views)

I don't know if I heard someone say it or if I stumbled across this thought myself...

"The first step in solving a problem is clearly defining the problem." Smiley Wink

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 29 of 47
(1,515 Views)

Hi Ray/Ben,

If one Device has perecedence over the other can you not define it in the truth table as follows?

 

IP1...IP2...OP

1...x...1

Where IP1 has Precednce over IP2 and x is dont care.  Therefore the OP in this instance is defined by IP1 only

Craig



Message Edited by craigc on 06-19-2008 08:38 AM
LabVIEW 2012
0 Kudos
Message 30 of 47
(1,511 Views)