Help with studio 5000

[drbitboy]

@parky: nice; you have a more positive view of humanity than I do.

You make an interesting point in the Rung 3 comments about whether the [NO Auto_Run] should go in the Latch/Start logic or in the (not-)Stop logic of the Start/Stop Circuit pattern. That is a topic worth the OP's time once they have the basic functionality working.

Sidebar: in Rung 3, the two NOs testing the Print_Retracted_PX and Auto_Run bitboxes can be removed from the latch/Start logic, because they both already evaluate to True if the following ANDed (in-series) [NO test of Print_Del_DN timer done bitbox] evaluates to True cf. Rung 2.

 

[parky]

Yes that is correct, I added the timer for a "print Residence" time afterwards (thought that just reaching the extend position then instantly retracting could cause bad print) so just junked that in and had a print retract latch I removed but did not bother taking out the redundant contacts. In saying that, it is often better to leave in interlocks like this in the event that for some reason the logic is reversed back or changed sometimes there can be a tendancy to miss interlocks so no real problem.

 

[arpus4KM]

all you've learned is that occasionally you can find answers on the internet.

....My career is a lie!

 

[Mueller34]

As a student I found this and wanted to test my skill. I have worked out code for the stamp press with printer ink and was wondering if someone could take a look. I can PM it as I don't want to give the OP the answers to his homework

 

[arpus4KM]

As a student I found this and wanted to test my skill. I have worked out code for the stamp press with printer ink and was wondering if someone could take a look. I can PM it as I don't want to give the OP the answers to his homework

sure, pass it along.





With the effort shown in the original posts. I doubt the OP would be able to pass off working programs as his own in person if he were ever asked a question about it. Maybe if he were to spend some time learning the fundamentals, but the original attempts at deceit tell me he he doesn't know enough to pass something off as his own anyway.

Not trying to be mean, but, once you "get it", you can look back on this and see how far off that screenshot of the other logic was from being an actual attempt.

 

[Mueller34]

sure, pass it along.





With the effort shown in the original posts. I doubt the OP would be able to pass off working programs as his own in person if he were ever asked a question about it. Maybe if he were to spend some time learning the fundamentals, but the original attempts at deceit tell me he he doesn't know enough to pass something off as his own anyway.

Not trying to be mean, but, once you "get it", you can look back on this and see how far off that screenshot of the other logic was from being an actual attempt.

Thank you after seeing this I decided to just set it out there.

 

[arpus4KM]

Thank you after seeing this I decided to just set it out there.

it appears in rung 3 you used Local:1:O.Data.1 (Extend) when you meant to use retract based on the logic.

 

[Mueller34]

it appears in rung 3 you used Local:1:O.Data.1 (Extend) when you meant to use retract based on the logic.

Yes I did mean to have that be retract, and seeing as the design was for an extend solenoid, and none for retract so I'm guessing the valve would be a 2 position where unenergized would return, I would just remove the top part of that branch so when the limit was triggered the timer would go, counter would count, and sequence could continue or stop based on the counter value.

Other than that would this be passable?

 

[arpus4KM]

Yes I did mean to have that be retract, and seeing as the design was for an extend solenoid, and none for retract so I'm guessing the valve would be a 2 position where unenergized would return, I would just remove the top part of that branch so when the limit was triggered the timer would go, counter would count, and sequence could continue or stop based on the counter value.

Other than that would this be passable?

just removing the top part wouldn't work, because as soon as you transition from that sequence, the OTE would be false and it would instantly retract instead of maintaining extended. you may introduce an error into it where it's on too short of a time to operate correctly. The other issue if you are going by the intial paper for OP, you only had 1 cylinder in the program and not the two working independently with their own sequence and counter.

the last machine I did from scratch with a lot of assembly moves had a common theme.

all solenoids were spring return, so Latch/Unlatch would be the extend, return.

All rungs had this basic theme.

IF sequence needed = current sequence number
then start Fault timer
and check physical position of machine to ensure it's in the right location.
If the machine is in the right position, and in the right sequence step
then OTL the next cylinder move
If the Machine cylinder completed the move then MOV the next sequence step into the sequence register.


a combination of checking for machine state, sequence, and move completion. if it doesn't complete the move while in that state after X time, then it completes a fault timer.

 

[Mueller34]

just removing the top part wouldn't work, because as soon as you transition from that sequence, the OTE would be false and it would instantly retract instead of maintaining extended. you may introduce an error into it where it's on too short of a time to operate correctly. The other issue if you are going by the intial paper for OP, you only had 1 cylinder in the program and not the two working independently with their own sequence and counter.

the last machine I did from scratch with a lot of assembly moves had a common theme.

all solenoids were spring return, so Latch/Unlatch would be the extend, return.

All rungs had this basic theme.

IF sequence needed = current sequence number
then start Fault timer
and check physical position of machine to ensure it's in the right location.
If the machine is in the right position, and in the right sequence step
then OTL the next cylinder move
If the Machine cylinder completed the move then MOV the next sequence step into the sequence register.


a combination of checking for machine state, sequence, and move completion. if it doesn't complete the move while in that state after X time, then it completes a fault timer.

I am a little confused...

There were 2 "problems" posed by OP one with 2 cylinders moving independently and one with a single cylinder with an ink stamp. The program I did was for the single cylinder...

I am verifying position by checking for the limit switches before starting the dwell timer...

 

[drbitboy]

Thank you after seeing this I decided to just set it out there.

Nicely done, typos notwithstanding!

A few comments:

• Rungs 0 and 1, and assigning a value to CyclePause bitbox, would be more concisely, canonically, and recognizably implemented as a Start/Stop Circuit pattern cf. here.
  • That would invert the sense of the CyclePause bitbox, so maybe Auto or NotPaused would be a better name.
  • @parky's code is an example of this.
• It's a personal preference only, but I would not put the CycleCounter.DN as part of the not-Stop condition, as it is redundant.
  • With it in that place, the operator has to press two buttons, [Reset SS] and then [Start PB], to restart automatic operation.
  • Without it, the operator has to press but one button, [Reset SS], to acknowledge a new ink cartridge is installed and restart automatic operation.
• The [XIO LS2_Extended] on Rung 2 is possibly unnecessary, as once the extended limit switch is activated, the SequenceValue would be set to 20, and Rung 2 would stop extending the stamp (i.e. Rung 2 would write a 0 to [Stamp Extend Solenoid]) on the next scan a few milliseconds later.
  • But leaving it in does no harm, and possibly avoids both extend and retract commands being active at the same time, if there was a retract command.
  • Also, leaving it in means the stamp can start extending right away when [Start PB] is pressed
• The one-shot instruction feeding the count-up instruction is usually unnecessary. although it does protect against the counter ending up with a value of 1 if the reset button is pressed while the timer is running after any of the first 19 stamps.
• With only three possible values for SequenceValue, the sequence step approach is a bit of overkill; those states could as easily be defined with combinations of bitbox values. That said, the step approach does allow for easily extending the capability in future, if needed, and sometimes the combinations of bitboxes do get extreme.
• We could probably debate for a long time about the optimal trigger for the counter and how to ensure the box is stamped.
  • @parky added a short timer triggered by [LS2 Extended] before allowing the stamp to retract; depending on the physical layout, that could be a necessary addition.
  • If the system is paused after the stamp prints a box but before the [LS1 Retracted] bitbox becomes 1, and the stamp retracts, then that box would not be counted with the current code.
  • I would use the [LS2 Extended] bitbox to trigger the counter, but it probably does not matter much.

 

[drbitboy]

just removing the top part wouldn't work, because as soon as you transition from that sequence, the OTE would be false and it would instantly retract instead of maintaining extended. ...

Certainly, but it also depends how the limit switch and the stamp are physically implemented.

Perhaps the switch allows the stamp to contact and then compress the box a bit before triggering.

Or the stamp could be on a spring on the end of whatever (rod?) pushes it, so that spring would compress with the stamp on the box while the solid rod keeps extending until it hits the limit switch.

In either case, a timer with the limit switch bitbox equal to 1 might, might, be unnecessary.

 

[arpus4KM]

Certainly, but it also depends how the limit switch and the stamp are physically implemented.

Perhaps the switch allows the stamp to contact and then compress the box a bit before triggering.

Or the stamp could be on a spring on the end of whatever (rod?) pushes it, so that spring would compress with the stamp on the box while the solid rod keeps extending until it hits the limit switch.

In either case, a timer with the limit switch bitbox equal to 1 might, might, be unnecessary.

I don't think I've ever seen a school "lesson" with enough information about the physical machine to make a good program from the getgo. Typically missing valve types, cylinder actions, limit switch placements, etc.

 

[parky]

Yes as I posted earlier, many of these assignments are poorly thought out & open to interpretation. When I start coding typically for this type of application I often put timers in even if I do not think they will be required, normally I just delete them but sometimes reduce the time to minimum.
Mueller: I took a quick look at your code & appart from the small mistakes it is a good effort, well documented, however, It is difficult to say if it is what you call a pass.
Many tutors have their own blinkered way of doing things, I have witnessed this, for example: one of my apprentices did a project where a pick & place system could have 3 possible ways of operating, apparently most students used separate routines for the 3 operations i.e. a typical operation rather than one bit of code that could happen twice was programmed as two separate operations, however, our apprentice spent a couple of weeks with me where we spent considerable time on one of our batching systems, this was recipe driven & I remember explaining to him that the recipe determined what was added to the batch & in what order, and there could be two or more additions that were the same ingredient so the software was designed with that in mind.
He decided to use this way of producing the relevant code, the tutor seemed to indicate it was too complex & did not follow what virtually every other student had done I.e. A 3 position selector that enabled each of the 3 routines, even though the apprentice explained that he used the switch to determine the order of operation in an array & call each function depending on an integer value so only needed to code each operation once. I looked at his code & found it easy to follow, did not repeat itself, small in size.
The company I worked for sent every engineer on a manufacturers course, I believe this was a condition of becoming an approved system integrator for them, it turned out that I seemed to know at least what the tutor did & probably more as I had been using it for a number of years, one thing I commented on was as this was a basic course for beginers it lacked the basic fundamemtals i.e. how a PLC scans, how the I/O is refreshed & other important functions, surely for beginners this is a must to understand how you can use the logic to perform some operations, how many times have you come across posts on this forum where the OP did not know about how a PLC runs the code, examples are set/reset in the scan, duplicate coils & their effects oneshots etc.

 

[Mueller34]

Thank you parky, drbitboy, and IanM8040 for your input. I rely heavily on the things i can learn from you all on this forum as I get into integration and automation. I can see everyone has their own way to develop a program, but I see at the heart whatever is made needs to be functional, provide room for future developments, and be understandable. The latter being very subjective even amongst other integrators.

Thanks again!

To the OP i hope you take learning this information seriously and put forth a little more effort. The people on this forum have a lot of knowledge to share if you show you apply yourself and don't just search for a quick/easy answer.