Data from lab devices

General Discussion
1

I’m not sure this is the best place to talk about this, but I’m looking for advice on how to achieve the following:

We have a qc lab that has a number of devices (scales, gc’s ph meters, etc.) whose data they’d like to have go directly into our database. The simple version of this is that we hook up the serial outputs from the devices to a plc using Kepware’s U-Conn (as recommended by Carl G. on another forum).

However, the problem is each sample tested has to be associated with a sample id, for example a packaging batch #, or a fermentation batch #, etc., so that when the data is sent to the db it is properly associated with its parent record. These id’s are in the same database that the device data is being sent to. So, the ‘workflow’ (so to speak) is something like the following:

Lab Device A has a carousel holding 20 samples, which are automatically fed into the machine and the results of each test are spat out on a roll of paper as the machine generates them. A clipboard is kept next to the machine, and the sample id from the db (packaging run, tank number, or something like that) is recorded for each sample slot in the carousel, and when a result is produced by the machine, it is copied to the clipboard. Sometimes a rush sample comes in and it is moved up in the carousel, in which case the clipboard is edited as appropriate. At the end of the day, the data from the clipboard is entered into the db.
The data acquisition version of the above would have to look something like: A computer stands next to the lab device, with 20 dropdown list boxes containing a list of all the packaging runs, tanks, etc. that could be brought in for a test. The lab device serial output is connected to this pc. The lab tech identifies what sample is in each carousel slot using each of the 20 dropdown boxes, sets the machine in action, and as the device produces data it is fed into the pc and associated with the apporiate sample id. The pc is connected to the db (via factory pmi?) and sends the two groups of data (sample identifier and analytical data, now married together) to the db.

In this version, the device has to communicate to a pc, so I suppose kepware’s uconn is not the right thing. We have looked at winwedge, but maybe someone has another idea.

And, more fundamentally, is there a better approach to doing this than what I’ve outlined above? Thanks for any who took the time to read this!

2

Actually, I think that Kepware’s U-Con driver is perfect for this. It doesn’t have anything to do with a PLC - its for direct serial-to-pc drivers (see kepware.com/Products/products_UCON.html )

I think it would be easiest to do if you reverse your order - that is, let the machine read all 20 samples, and then have an operator fill in the IDS.

To do this, I would do something like this: Have a table that has three columns (index, SampleID, Analytical Data Value)

To start, clear out the table, and have the operator start the machine

Have a FSQL group that is triggered to run whenever a datavalue comes in from u-con. Have it insert a row into the table, leaving the SampleID blank.

When you’re done, present a window to the user with the 20 entries in the table, and have them fill in the sample ids. Then have a button at the bottom that sends the entries over into your main history table, and clears the table out again for the next run.

Its just a sketch of an idea, but it should work…

3

Hi Carl: I think I like that approach. It seems simple and quick. We’ll experiment with it. Thanks.

4

Cool! Please keep us posted on how it works, especially "gotchas".

5

We have the UCON up and collecting data. Once we figured out if we needed to ask for the data, or if we just wanted it to come in whenever available (solicited vs unsolicited) we started seeing the data coming in.

We configured it unsolicited, one string read of 487 bytes and 10 tag updates. We had to count bytes total coming in and between data we were interested in, so we were updating tags with the correct information as there were no control characters for us to key off of.

We had timing issues as the default wait times are 1000 ms, but since we are attached to the printer via a Y cable, it takes more like 20 seconds for us to receive out entire datastream, so we switched that value to 30000 ms before our tags would update.

If the number of bytes for my data string read was incorrect, I would not see even part of the data come in. Likewise, if my wait time was not long enough, I would not see any information in the Kepware tags.

Once the tags were populated in Kepware, it was easy to get them into FSQL. I am currently working on the Lab entry screen for them to match up tests. The lab requires the sample information be entered before it is put through the machine, so I am working on an indexed list they can match up with the tests as they run through the machine.