Logic Efficiency help

[J. Feldman]

Hey All,

I have a newbie question I'm hoping to get help with.

I am developing a controls system for a Loss-in-weight feeding system. The operators load a can of materials and it is fed through a screener. We have 14 of these stations. We reuse the same set of cans, but they are all bespoke with varying weights. I wanted to implement a system to store their tare weights so the LIW feeding is as accurate as possible. Each can has an assigned number engraved on it, and we have a list of their Tare weights, but the operators don't have access to that info. I wanted to add an input to the HMI where operators just punch in the can number, and the PLC adjusts the tare weight to the correct value. I have a common "Station" screen built in FactoryTalk, with parameters for each station (Can #, feed rate setpoint/actual, TARE weight, etc.). Here-in lies my question:

What is the easiest way to achieve this? I know I could have the logic check the can number assigned to the station, and then move the correct weight into the TARE value for that station; but the only way I know how to do this would require essentially 121 rungs of logic (for each can) and then copying that 14 times, for each station. There must be a simpler way to accomplish this without taking 1694 rungs, right?

Thank you in advance for your help!

 

[ndzied1]

It would help to state what software and PLC you are using.

 

[J. Feldman]

Sorry:

PLC is a CompactLogix 5343 (1768-L43)
Logic is Logix Designer
HMI is a Panelview Plus 7 Performance (19")
HMI program is FactoryTalk View Studio

 

[plvlce]

Sounds like what you need is some indirection.

As an example:

Set up your tags as an array, for example TARE_Weight[x] where x is one more* than the number of possible weights (or more if you want to future-proof it). Set each member to contain the value matching the can # (TARE_Weight[1] contains the weight for can 1 and so on). Then when the operator punches in the can number to, say, a tag named Selected_Can, do a copy from TARE_Weight[Selected_Can] to wherever you need the value.

You can potentially use similar indirection to determine which station you are dealing with.

cf the second point of drbitboy's signature

*for this example the 0th element of the array is unused.

 

[parky]

I think the best way is create a file (depending on PLC) say for example a set of memory locations (array) for demonstration purposes assume only 50
Each of these would contain the tare weight so the array would be
0-50 of real
to make the maths easier ignore array 0 populate the array with the weights in order of the number i.e. can number for example
Array[1] Can 1
Array[2] Can 2
& so on.
Then when the operator types in a can number say 20 your logic will indirectly address Array[20], not sure of the PLC you are using but for example
Operator enters can number into a field on the HMI, this field can act as a pointer so your logic will be move Array[operator_Entry] to say a variable called Tare_Weight.
perhaps you need some logic to do this either an operator accept button or perhaps some other method of transferring the data.
I have done something similar but had to put it into a queue so that the information was shifted as the parts went into the process.
Your information is a little vague but indirect addressing using the above seems to be the best way to go.
The process is as follows
Operator enters 20 into the can entry
the pointer now contains 20 use the pointer to point to location 20 & move it into the Tare_Weight variable.

 

[drbitboy]

cf the second point of drbitboy's signature

Heh.

+1 (and not just for the reference to me), especially the bit about future-proofing.

TL;DR

What would be really sweet is an RFID tag or bar code on each can, and then the PLC can read each can's code and do the lookup on its own.

 

[plvlce]

What would be really sweet is an RFID tag or bar code on each can, and then the PLC can read each can's code and do the lookup on its own.

Get the logic set up and working first. That would indeed by a nice and relatively straightforward way to eliminate potential operator entry error though.

 

[dmroeder]

Rule number 1 of indirect addressing, be sure you check that the value of your index does not exceed your array boundaries before trying to use it. If the operator fat-fingers a value in (adds an extra digit), you will fault your controller.

 

[drbitboy]

Rule number 1 of indirect addressing, be sure you check that the value of your index does not exceed your array boundaries before trying to use it. If the operator fat-fingers a value in (adds an extra digit), you will fault your controller.

arrgh, you had to tell OP this?

I wanted to see the post when he comes back with some urgency about how the line keeps going down whenever the dyslexic operator is on a shift.

 

[parky]

Yes take note about making sure the operator can only enter numbers from say 1 to the number of cans (simple on an HMI just set the limits, You could start at 0 but then you need to subtract 1 from the pointer
Here is a simple way to indirect address
Note: here using a button to accept the entry gives chance for the operator to change his mind
If you look at the screenshot the entry field is 3 so indirectly it is pointing to array[3]

 

[J. Feldman]

Thanks for the input, everyone!

After mulling over it, I think I ended up arriving at the same solution a lot of you mentioned:

Station1.CanNumber gets the value from the operator input. I have an array of CanWeights[460]. Move function sends CanWeight[Station1.CanNumber] to Station1.Tare.

The messy bit is that, after years of cans being retired and new ones being built, the 121 cans are not in sequence, since numbers weren't reused. So the array will have a LOT of empty values XD.

I like the idea of RFID too, but I'll have to check with QC, since it may be a FOD concern given the sensitive nature of the materials we produce.

 

[parky]

Personally, If you are going to spend time upgrading the system then it would make sense at this point to re-number the cans anyway, RFID is a good way but if these cans get bashed quite a bit could end up with a lot of mis-reads, also the cost of a reader & the chips would be higher.
From that point it would also make sense that if a can is replaced then give it that number & reenter the tare weight.

 

[J. Feldman]

I raised the same point to the powers-that-be. Cans are rarely replaced but to me it makes the most sense to have a new can just adopt the old can's number, and we can adjust the new tare weight when the retirement happens.

 

[cardosocea]

This is not what you want to hear, but I'd steer away from asking the operator input for this. If you only have 10 cans, it's ok... otherwise, I can see mistyping becoming an issue.

You could potentially cross reference the tare of the unit versus the actual weight and typed number...

Parky's solution would be even better so the operator is not involved at all. I'd imagine in certain environments, a can would be retired with its number until a few years passed to avoid confusion in records should an investigation be required. But I may be wrong.

 

[parky]

There is always a problem with operator entry, a couple of systems I did had different ways, one was a pallet strapper, there were something like 24 strapping programs, the pallets could vary in size & styles, it was rather complicated, most of the time the pallet would be measured, a check if the bottom of the pallet had a full length board or just legs, and the strapping ws based on this information for example single strap (small pallets), two straps one at 90 Degrees, 2 straps long pallet, 3 straps extra long palllet, if no bottom runners the strap fed directly under the pallet or if bottom runner then swords would extend between the top & bottom runner, it also had sensors so the pallet was measured, placed in position, if the sensors could not see a route for the swords or strap it would try 3 times by moving back/fwd so many programs. the HMI had an extension keyboard with 24 keys, when a program type was automatically selected the led for that button would flash if the operator decided that this pattern was not correct he could press another pattern to override it. fortunately if the operator made a mistake then if as the pallet was put into position should it not find a clear strap route it would stop. This required quite a few sensors to eliminate a crash situation but not many things can be fullproof. The other was very similar to the OP's however, it relied totally on the operator to select the correct spray pattern, this station was some distance from the spray booth so not only operator selection was required but it had to be passed to a shift register as there could be perhap 5 components in the queue, again we had to give the facility for the operator to modify any location in the queue.
So it would be prudent to look at all the scenarios to reduce or allow modification due to operator input errors. I suppose in the end it will come down to cost & operator training.
The information given is a little sparse, questions that come to mind are:
OP talks about loss in weight, but is also talking about tare weight of what we can only assume is different sized bins, what about the contents weight how does the system know this, is the gross weight of the bin checked somewhere i.e. at the position where I assume it gets emptied i.e. what I would term the loss in weight to decide when the bin is emptied.
Should the latter be the case, what tollerances will there be for deciding the bin is empty based on the tare weight selected, for example how accurate is the scale, imagine a situation where a bin tare weight is say 10.32 kg, so the bin is emptied, but the current weight is showing 10.33 kg due to minor differences in the stored net weight & the current weight measured.