OkiePC
Lifetime Supporting Member
D'ya get connected yit?
Also, let me know if you want the unedited excel sheet to go with your sequencer. It will open with the data intact, if you decline the option to update remote data sources when Office opens the file.
I can post the .xls file and some instructions for using it with your RSLinx configuration if you have a version other than RSLinx Lite.
Then you can S&R the cells with RSLinx DDE links topicname and update them to match your online file.
And don't forget to add the mode logic to control the AUTO and MANUAL mode bits that I left dangling in the example.
Post an update if you can...
The most important part of any PLC sequencer IMHOkieO, is the excel chart that documents the process most completely. If you automate the documentation, you will, no doubt, be able to quickly and easily resolve any issues that affect the machine control.
At one time, I built an excel sheet for a complex tire assembly machine that included buttons to read the existing sequence, or send the edited sequence to a PLC5. I used very crude VBA underneath some simple buttonclick events.
With that simple tool, I could reconfigure the sequence to build a test tire or to refine quality of the product and it was in an organized, yet powerful little excel file with pop-up comments, and units conversions...much easier on the programmer or technician than RSLogix binary radix data tables.
When it checks out in chart form, and you make use of your design document as a source for tag names and/or descriptions throughout the runtime applications, you can really have slick code that is self diagnostic, self documenting, extremely powerful and flexible too.
Once you build the strategy for presentation and implementation, the work of building the sequencer becomes childs play.
My eyebrows raised some earlier in the thread when you said you combined steps and shortened the sequencer.
Fewer steps is rarely better, but spares can be priceless!
Hmmm, that applies to wires, and many other aspects of our work besides steps, huh?
Usually I find that extra steps inserted in the sequence is a more common upgrade to a sequencer than trimming out microseconds of cycle time by shortening the overall sequence.
Spares (identical steps that get one scan of the PLC code) are useful later on when you get into the nitty gritty details and find out that you need a delay between the activation of two devices, or need to insert an action that you forgot, or the salesman already told his customer your machine could perform.
Most sequeners get additions as product quality, or complexity is driven forward.
If you are under a hundred steps and still have plenty of memory (which you do), then make sure you have one unique step for each device that must change states during a step change.
Example: If, in step 3 of a 57 step sequence, you need to turn on two motors and a solenoid valve at the same time. Make three steps that have the same output and input conditions.
Turn them all on in steps 3, 4, and 5. And look for the same input conditions in steps 2, 3, and 4.
The PLC will be in steps 3 and four for a single scan each, and then be in step 5 until the input MEQ is satisfied, then go on to step 6 immediately.
Later on it is a piece of cake to split up the sequence into different steps if you find out later that that cylinder moves so slow, that it needs to get a head start for optimal cycle time, and now you have to insert a step and scoot all your bits down in hte table, all 54 remaining rows of them...
Not a big deal if your sequencer PLC has code built to help automate the design by , but when you are didling the bits by hand, it is nice to leave behind spares.
The PLC sequencer, using the MEQ method for sequencing hte inputs as in my example, can advance through the spares at its average scan rate, and you will not know they are even there until you need them.
This description of the scan is not necessarily true with the SQI (PLC5) or SQC (SLC) instructions. Those instructions require a false to true transition in order to "go true" (PLC5 SQI) or set the FD bit (SLC).
That's another reason I prefer the MEQ/MVM over the SQC/SQO instructions, in addition to externalizing the step control.
External step control: By ditching the SQO in favor of the MVM (or MOV if your mask is a constant FFFFh) you can split up the bit file mapping portion of the sequencer from the counting portion. You will probably find it useful to be able to step forward through the sequence, and even maybe to back up a few steps and go back into automatic mode.
That type of control can be very effective fro operations and maintenanceespecially with some form of numeric display for the step number.
Then, you can end up with a machine that can "limp along" with a failed limit switch, for example, by allowing the operator to switch to manual and step forward.
If he needs to back up two steps to repeat a part of the process after manual intervention was required, he can do that too.
Just more food for thought on your sequencer.
piEAce!
Also, let me know if you want the unedited excel sheet to go with your sequencer. It will open with the data intact, if you decline the option to update remote data sources when Office opens the file.
I can post the .xls file and some instructions for using it with your RSLinx configuration if you have a version other than RSLinx Lite.
Then you can S&R the cells with RSLinx DDE links topicname and update them to match your online file.
And don't forget to add the mode logic to control the AUTO and MANUAL mode bits that I left dangling in the example.
Post an update if you can...
The most important part of any PLC sequencer IMHOkieO, is the excel chart that documents the process most completely. If you automate the documentation, you will, no doubt, be able to quickly and easily resolve any issues that affect the machine control.
At one time, I built an excel sheet for a complex tire assembly machine that included buttons to read the existing sequence, or send the edited sequence to a PLC5. I used very crude VBA underneath some simple buttonclick events.
With that simple tool, I could reconfigure the sequence to build a test tire or to refine quality of the product and it was in an organized, yet powerful little excel file with pop-up comments, and units conversions...much easier on the programmer or technician than RSLogix binary radix data tables.
When it checks out in chart form, and you make use of your design document as a source for tag names and/or descriptions throughout the runtime applications, you can really have slick code that is self diagnostic, self documenting, extremely powerful and flexible too.
Once you build the strategy for presentation and implementation, the work of building the sequencer becomes childs play.
My eyebrows raised some earlier in the thread when you said you combined steps and shortened the sequencer.
Fewer steps is rarely better, but spares can be priceless!
Hmmm, that applies to wires, and many other aspects of our work besides steps, huh?
Usually I find that extra steps inserted in the sequence is a more common upgrade to a sequencer than trimming out microseconds of cycle time by shortening the overall sequence.
Spares (identical steps that get one scan of the PLC code) are useful later on when you get into the nitty gritty details and find out that you need a delay between the activation of two devices, or need to insert an action that you forgot, or the salesman already told his customer your machine could perform.
Most sequeners get additions as product quality, or complexity is driven forward.
If you are under a hundred steps and still have plenty of memory (which you do), then make sure you have one unique step for each device that must change states during a step change.
Example: If, in step 3 of a 57 step sequence, you need to turn on two motors and a solenoid valve at the same time. Make three steps that have the same output and input conditions.
Turn them all on in steps 3, 4, and 5. And look for the same input conditions in steps 2, 3, and 4.
The PLC will be in steps 3 and four for a single scan each, and then be in step 5 until the input MEQ is satisfied, then go on to step 6 immediately.
Later on it is a piece of cake to split up the sequence into different steps if you find out later that that cylinder moves so slow, that it needs to get a head start for optimal cycle time, and now you have to insert a step and scoot all your bits down in hte table, all 54 remaining rows of them...
Not a big deal if your sequencer PLC has code built to help automate the design by , but when you are didling the bits by hand, it is nice to leave behind spares.
The PLC sequencer, using the MEQ method for sequencing hte inputs as in my example, can advance through the spares at its average scan rate, and you will not know they are even there until you need them.
This description of the scan is not necessarily true with the SQI (PLC5) or SQC (SLC) instructions. Those instructions require a false to true transition in order to "go true" (PLC5 SQI) or set the FD bit (SLC).
That's another reason I prefer the MEQ/MVM over the SQC/SQO instructions, in addition to externalizing the step control.
External step control: By ditching the SQO in favor of the MVM (or MOV if your mask is a constant FFFFh) you can split up the bit file mapping portion of the sequencer from the counting portion. You will probably find it useful to be able to step forward through the sequence, and even maybe to back up a few steps and go back into automatic mode.
That type of control can be very effective fro operations and maintenanceespecially with some form of numeric display for the step number.
Then, you can end up with a machine that can "limp along" with a failed limit switch, for example, by allowing the operator to switch to manual and step forward.
If he needs to back up two steps to repeat a part of the process after manual intervention was required, he can do that too.
Just more food for thought on your sequencer.
piEAce!
