10-03-2005 01:46 AM
I am recording times taken for a production sequence to complete. The time is recorded in seconds by the plc, which counts upward from zero until the production sequence has completed, after a short pause the plc resets itself to zero and repeats the count for the next sequence. I would like to write the totals of each sequence to a tag so I can show total production times for each sequence in a table or on a historical chart.
I am unsure how to program labVIEW to take the total times for each repetition of the sequence and write the information to say, a tag. If anyone can offer an example of how I can retrieve these values I would be u-n-b-e-l-i-e-v-a-b-l-y grateful!!
Many thanks,
Stuart
10-03-2005 07:01 AM - edited 10-03-2005 07:01 AM
Stuart,
This works for me in a situation similar to yours:
In the PLC there is a counter monitoring the production cycle number. It is incremented at end of every cycle. Its value is written to a PLC data register (say R000). There is a DSC tag for that data register (Input).
In the PLC, there is a timer/counter measuring total cycle time. At the end of a cycle, just before the timer is reset (actually it is written at the same time as the Cycle Number increments), the value for total cycle time is written to data register (R001). There is a DSC tag for R001 (Input). This tag is not logged. There is also Memory tag for total cycle time that is logged and logging deadband is set to 0%.
In the LabVIEW code, R000 (Cycle number) is monitored. When its value changes at the end of a cycle, R001 (Total cycle time) is read (Read Tag.vi) and its value is written (Write Tag.vi) to the Memory tag for 'Total Cycle Time'. Since the memory tag has its logging deadband set to 0%, a value gets logged for every cycle even if it's the same value as the immediately previous cycle).
I have found that I need to put a brief delay (~5sec) after the Cycle number increments before reading R001 (to make sure the value for R001 in the DSC's realtime database has been updated to the new value).
Message Edited by Donald on 10-03-2005 08:02 AM
10-03-2005 07:34 AM
10-03-2005
11:32 AM
- last edited on
07-08-2024
05:57 PM
by
Content Cleaner
Hi Stuart,
"I would like labVIEW to count the cycle/recognise the end of cycle"
From your descriptions so far, the only indication that your HMI/LabVIEW DSC program will have that a production cycle is complete is/are:
1) there will be a "short pause" during which the Total Cycle Time value will stick at its maximum value; and
2) the Total Cycle Time value gets reset to zero.
Idea: Monitor the Total Cycle Time timer/counter/data register as an Input tag (not logged). Use a shift register in your state machine's ** while loop to store the value from the previous time you monitored this Total Cycle Time tag. When the current value is < (less than) the previous value, a new cycle has started. Write the previous value to a 'Total Cycle Time' Memory tag that is configured to log.
" Also, I have not managed to configure a tag with a deadband of 0% without an error appearing in the configuration editor"
That's a headache. What kind of error message (if any) do you get? Have you tried it for different types of tags (Input, Memory, etc. etc.). What deadband(s) are you trying to set to zero?
There's a useful KnowledgeBase doc summarizing deadbands here.
If you want to have a logging deadband of 0%, you do have to have the Tag Engine Update deadband at 0% as well.
** Re: State machine
If you haven't done so already, you may want to look at examples of the use of a state machine as an overall structure for LabVIEW programs. Simple examples ship with LabVIEW. If you search this forum, you will find many discussions on its merits and different forms. There've also been a number of presentations/docs on the idea. A couple which come to mind are:
- Rob Humfeld's NI Week 2004 presentation here (the "State Machines" link at the bottom).
- LabVIEW Application Design Patterns from 2002.
Without the use of some kind of flavour of state machine, the block diagram for a LabVIEW DSC program can get messy and hard to debug very fast.