Siemens S7/TIA v18: Set & Reset Instruction...

[Mas01]

This code is working as expected, but it looks a bit clumsy w.r.t. setting of "Laser1 PASS".
Is there a neater way (different instruction) I should be using?
Thanks

 

[JesperMP]

looks fine to me.
I can think of a couple of variants, but they are not better.
Important is that the code is readily understandable.

I do dislike spaces in variable names though.

 

[Mas01]

looks fine to me.
I can think of a couple of variants, but they are not better.
Important is that the code is readily understandable.

I do dislike spaces in variable names though.

Cheers @JesperMP.
Yes, I'm starting to dislike the spaces, too, so I might change it later.

 

[cardosocea]

Silly question here... but, wouldn't the first comparison (<=) with a coil rather than a Set do what you want?

This is the ladder equivalent of

IF _condition_ THEN
   outout :=1; 

ELSE
   output := 0; 

END_IF;

What I suggested was:

output := _condition_; //In your case Var <= 1.0

 

[JesperMP]

I am guessing he only wants to perform the test when the condition "Data_block_1"."Calculate diff" is set, and the test result is to be memorized for use later.

Assuming I am right in the above, then a better representation is:

IF _condition1_ THEN
  IF _condition2_ THEN
   output := TRUE; // with memory !
  ELSE
   output := FALSE; 
  END_IF;
END_IF;

condition1 is when to perform the test.
condition2 is what to be tested.

 

[parky]

It will depend on the logic before the comparison if it is just a one shot and the output was just a coil it will turn off again.
One thing comes to mind though is if this is a ok to proceed or not ok then if the bit doing the test goes off how do you reset when complete, this is often a mistake made by many people, the best solution is to put the reset on a seperate rung (ideally the next rung) then if it is to be reset by some other logic as well then it makes it easier. This scenario often crops up i.e. if in transition of some kind of step the test is ok then the program carries on to the next operation, at some point perhaps the bit needs to be reset ready for a repeat operation but without knowing what the OP is doing exactly it is difficult to say. It is interesting that this seems to be a pass or fail, why is there no fail bit ? I would assume that there should be but perhaps that happens on another rung.

 

[joseph_e2]

My first though: the advantage to using Set/Reset is that the pass/fail value remains valid after the "Calculate Diff" flag goes false. The calculate flag may be very momentary.

 

[mk42]

Off Topic, but i just noticed you recently upgraded to V18, hi5, haha

 

[Mas01]

Off Topic, but i just noticed you recently upgraded to V18, hi5, haha

Aye, we splashed out on a full licence at v18, after the 21-day trial of the v16 licence expired.

 

[Mas01]

To add more detail:
The "Data_block_1.Calculate diff" is linked to a F-key on the HMI. When the user presses the F-key, the aforementioned bit is set TRUE.

When it is TRUE, a series of subtractions is performed (distances in mm) between the first set of measurements (from a "master" part", which is the "ideal" part) and the fresh-off-the-factory-floor part. If the distance differences at each laser location is less than 1mm (absolute), then the part is PASS (and can be dispatched to customer), otherwise it is FAIL and needs re-work.

Basically there will be a result of:
OVERALL PASS = Laser1 Pass AND Laser2 Pass AND.... AND Laser10 Pass

 

[Mas01]

It will depend on the logic before the comparison if it is just a one shot and the output was just a coil it will turn off again.
One thing comes to mind though is if this is a ok to proceed or not ok then if the bit doing the test goes off how do you reset when complete, this is often a mistake made by many people, the best solution is to put the reset on a seperate rung (ideally the next rung) then if it is to be reset by some other logic as well then it makes it easier. This scenario often crops up i.e. if in transition of some kind of step the test is ok then the program carries on to the next operation, at some point perhaps the bit needs to be reset ready for a repeat operation but without knowing what the OP is doing exactly it is difficult to say. It is interesting that this seems to be a pass or fail, why is there no fail bit ? I would assume that there should be but perhaps that happens on another rung.

Bang on the money - I think I'm seeing this problem in the code shown - I will create a separate thread for this question.

 

[drbitboy]

looks fine to me.
I can think of a couple of variants, but they are not better.
Important is that the code is readily understandable. ...

+1. Downtime - i.e. troubleshooting while the process is not running and therefore is not making money - is the primary, and perhaps only, consideration. I am not saying this logic may cause a problem, rather that the less troubleshooting time spent grokking/remembering what this logic is doing means more time spent focusing on finding the actual problem.

Set/Resets lend themselves to being implemented in an ugly way, but that is not the case here: as noted by others, although somewhat of a dog's breakfast , the Set/Reset instructions are at least very near each other, making it easy to understand.

The [<=] comparison instruction before the Set could be removed (see the red X in the top example of the image below), but it is likely more clear if not removed, and forces the reader to think about the significance of the N.O Contact on the trigger.

The image below may show a couple of the variants @JesperMP was thinking of, and I agree they are not better.

I might go with the middle one because it is a form of the easily recognized, canonical seal-in-based ladder patterns, and so more easily understood that Set/Reset with all the folderol feeding it, but would be purely a personal preference.

The bottom example is more concise, but it does not fit in as well with OP's original logic, where there are subsequent steps driven by the trigger.

Another consideration is what happens if the PLC cycles power and/or mode: should the value of PASS be reset to 0 if TRIG is not 1 on the first scan, as it would be with the bottom two examples, or would it be best for PASS to keep its value from before the mode cycle as it would with OP's original logic?

 

[parky]

does not matter if you use a seal in or latch/unlatch (S/R) if using SR just keep the logic close, almost certainly if you seal in or latch what ever version then if a fail then I assume you need to remove it, eject it or what ever, perhaps have a good/bad parts counters (don't use counters just increment words) then you have history of good versus bad parts perhaps store batch details in csv format on the HMI or even just have a rolling shift register of say the last 15 shifts work on the HMI.
As for the set/reset do what you feel comfortable doing it is certainly an American thing "Seal in", I do understand their reasoning seen many programs where set/reset are spread all over the place instead of next to each other & it does make it harder to read the logic & debug it, so if comfortable with SR then keep them next to each other. Using the compare as a seal in has no real benefit as it uses probably at least or more memory & processing time as a set/reset.
no idea about your control of this system but if manual as far as determining what happens to a bad part then it would be a good idea to keep either an alarm or message on the screen until operator removes the part, if automatic i.e. release good/bad part then ther same thing for example test is complete is it a bad part eject it into bad bin good part ejevt it into good bin, if you get say 3 bad parts then stop process as there is obviously a problem.
I have done many pick & place robots with 16 stations so a part is placed into a nest in station 1, in rotates to nect station, next part is inserted, next station checks if in correct position, & so on, so it had 6 stations for insertion 6 stations for checks a loading station & 2 extract stations (good/bad) it also checked if a part was inserted in the first station, if not it disabled the following stations from inserting components when at it's position, if a part failed to jet ejected it was allowed to go round three times then would stop on alarm. All the operations for each station were tracked by shift registers all this data was saved to csv files for retrieval.
I have no idea if you have put down on paper the theory of how you need this machine to work but it makes sense to have a brainstorming session with those who may need to know or have ideas, write down the sequence of events that need to happen i.e. make a flowchart it makes writing the program easier.
Do not fall into the trap of design as you go along it makes your code messy, creates bugs every time you make changes on the fly you end up with lots of effective redundant code, test as far as possible the individual functions.

 

[Mas01]

Thanks for the replies.
The process is like this: the operator locks the master part in a jig, then presses SAVE. This will save the 10 measurements. Operator removes the part and places the machined part into the jig (locknuts ensure the master part and new part are anchored in the exact same place). Operator presses SAVE again,and a second set of measurements are taken.
Then operator presses a F-key which initiates the calculation whereby if the master and new part are within 1mm of each other AT EACH of the locations, the overall result is PASS. A single out of tolerance is enough for the part to be FAIL. Operator removes the part and puts the PASS parts in one box marked "good"or whatever and FAIL parts go in a box called "rework " or whatever. For each save, the data will be recorded to a CSV file (this saving side I've not implemented yet).

 

[Mas01]

Edit...I just realised they haven't told me how each part is identified, whether it's got a serial number or what.
I'll ask customer tomorrow.