Studio 5000 Database

[vezdro]

Hello to Everyone all over the world:

I don't want to reinvent the wheel so I am asking others if they have programmed something similar to this and provide some advice. I am needing to record data, store it, record data again, and then print it to a label. Lets just say serial #, model #, pressure, temp, and tare weight. This is the first part of the data being recorded. Then when the vessel is filled, its moved to a scale to capture the gross weight. The final piece of this is to somehow matchup the recorded data to print on a label. I am confident on the programming side but this is my first time working on any type of database recording.

First recorded data
Serial 100 , Model 200, pressure 300, temp 400, tare weight 500 (gets stored)

Second recorded data
gross weight 600 (gets stored)

Match the data to print on the label (somehow match up the data)
Serial 100 , Model 200, pressure 300, temp 400, tare weight 500, gross weight 600

Applications/Equipment: Studio 5000, FactoryTalk ME, L33ERM and PanelView Plus 7 Performance

 

[Ken Roach]

Welcome to the PLCTalk forum community ! Thank you for the details of your equipment and your application.

To be sure I understand, I'd like to ask some questions.


I assume most of the operator interface is through the PanelView Plus. Will your operators manually enter the serial number, model number, pressure, temperature, and tare weight ? And then the gross weight ? Or are there sensors like RFID or barcode or other ways to identify the vessel and the batch ?


Do you already have a label printer that you are going to use, or do you have to select and learn to interface with it ? Do you need to print straight ASCII text, or are there logos or barcodes or QR codes that need to go on the label ?

You say that you need plan to store the batch data in a database. Will it be recorded long-term or otherwise analyzed, or does its value end once the label is printed ?

What sort of databases do you have available to you ? Are there any general-purpose computers besides the PanelView Plus available ?

The PanelView Plus is not super flexible for this sort of work. It supports only a small handful of printers, and basically only for doing screen prints. But you do have the PV+7 Performance, which at least has access to the Windows desktop and applications you can run there. I believe that the PV+7 Performance Series A terminals still had Windows CE 6, while the Series B run Windows 10 IOT. Reports are that wasn't actually an improvement in some ways; whatever OEM build RA did with Win10 IOT initially broke some simple stuff like DHCP and the screensaver.

PanelView Plus can print a screen as PDF. Can your printer grab a PDF file via FTP and print it ?

 

[Geoff White]

Do you need an actual database for long term or just something like it on the PLC to handle a finite number of records? If the latter I have used an AOI to act as a dumb database of key,value pairs.

 

[vezdro]

Sorry I forgot the scanner.

Correct, operators will interface through the PanelView Plus. The operators will place the vessel on the scale to scan the serial number and model number, then I guess create some type of trigger to capture the pressure, temperature, and tare weight to record the data while the vessel is in place. The vessels have a barcode serial attached. After the vessel is filled, maybe create another trigger to matchup the data and then print to a label.

Yes, the we have a Zebra label printer and have had success using an RTA ASCII to Allen-Bradley PLC.

At the moment the recorded data will be stored temporarily but I have a feeling that it will be requested to store it permanently. Depending if there is no cost in finding a permanent solution, I might go that route.

Currently have a VM Microsoft SQL server and GE Historian server. Trying to avoid using a general-purpose computer.

As I mentioned we should not have any issues printing but we will see once we match up the data to print on the label.

 

[Aardwizz]

Is your application some sort of filling line, where you are trying to move a "Database Record" (#, Temp, Wt, etc) down the line in tandem with the vessel, so that when the vessel gets to the end, your Zebra printer has the data it needs associated with that part to affix the proper table?

For that, you'll need some sort of FIFO, either using the FFL / FFU instructions, or the simpler COP(Array[1],Array[0]) trick.

The hardest part about parts tracking is knowing when to index / trigger the array to shift. If you have an indexing conveyor, that's easy, because you'll trigger the system to index one station at a time. It gets harder when you have a simple conveyor and are trying to convert its RPM speed into a linear distance travelled and pulse every distance. Worse is when the containers can slip on the conveyor. Then unless you have a photoeye, a way to ensure gaps that can see individual bottles and the ability to ensure that there no between the "stations" or the database (i.,e, a reject station to take a bottle out of the middle of the lineup), it gets much harder.

Many of us have done these kinds of applications. More details about what you have would help.

 

[joseph_e2]

You said that the operators place the vessel on the scale to "scan the serial number and model number". Is that encoded in a barcode label already on the vessel? If so, do you have another barcode scanner at the label printer station? It looks like the pressure, temperature, and tare weight are measured while the vessel is on the scale. How are the vessels moved from the scale to the fill station and from there to be labeled?

If the vessel starts with a barcode serial number label, I would probably add a simple barcode scanner at each station that "does something". Especially if the vessels are moved around by the operator. How big are they, anyway?

 

[drbitboy]

The new hire was getting a transition handover from the old hire who was leaving the job. After many details were passed, the old hire said: I've told you everything I could, but still sometimes things will go south. When that happens, in this top drawer there are three envelopes; take out the top envelope and do what it says. Then the old hire leaves. The new hire listened carefully and was a quick learner, so everything went well for a few years. Then it all went to pot one day. Remembering the original transition, he took out the first envelope and read "Blame marketing." He blamed marketing, and things got back to normal. A few years after that, same thing, the envelope says "Blame R&D," and things got back to normal. Finally, a few years later thing got way out of hand, but they confidently opened the last envelope: "Make up three envelopes."

What does that have to do with the price of potatoes? Nothing, but I always think of that when I see a problem with threes.

It sounds like there are three stations: a scanning/tare weight station; a gross weight station; a printing station. Each station has a trigger for when that stations data should be recorded. Maybe the printing station is not a real station, but if so that only simplifies the process. And the issue is that there can be multiple containers passing through the system at any time, so when a scanning/tare trigger even is seen for a new container, there might be several containers between that one and the printing station.

The property data can be stored in arrays: an array for the serial #; another array for the model #; etc. (pressure array; temp array; tare weight array; gross weight array). It could also be a single array with one attribute for each property, similar to what was suggested by @Geoff White. The implementation details do not really matter, but the key idea is that each container that comes by could be thought of (i.e. modeled as), in the PLC, as a set (entity) containing one value for each those properties, or as a row in a spreadsheet where each column contains one property for that container.

All that is needed is that

• the array(s) be sized for well beyond the number of containers in the system at any given time (say this number is 16, so ARRAY[0..15] of DINT), and
• there are three independent indices, one for each station trigger: idxScanTare; idxGross; idxPrint

In the spreadsheet model, each station index represents the next row where that index's data will be written.

Each station's trigger (one-shot) does two things: firstly, it writes that station's data to, or prints the data from, the array(s) at that station's index (row); secondly, it increments the station index with rollover.

"With rollover" means that when an index's value increments from 15 to 16, the value is reset to 0.

This can also be done with FFL/FFU and multiple arrays, where new data are added via an FFL(s) for Scan/Tare and another FFL for Gross, and via multiple FFUs for Printing.

The only tricky part will be initializing the system on startup, or re-initializing the system after an upset.