Hi all: Any thoughts on how possible it would be to use factorypmi/sql to capture data streams from lab devices, such as scales, ph meters, gc’s etc. There are apps out there for that, but it strikes me that what we are doing with your products is pretty much the same (just with plc’s), and I would much prefer continuing down the pmi route than any other. thanks. David
Hi All: I don’t know if you’ve seen the above question, but how possible is something like this:
The qc lab has about 10 devices, from scales to gc’s to dissolved o2 meters, etc. Could we somehow link them to a lab plc? These devices have rs-232 outputs (at the very least), so could we not attach a serial device thingy to the plc for each device, then use sql and pmi to read the data streaming off the device?
Eagerly awaiting a reply…
You could also use serial to ethernet devices (I use a bunch of them on another project I’m working on), and get the data directly over enet. Then you wouldn’t need the PLC at all.
I don’t know much about this kind of stuff. It seems to me that each device is going to have a different kind of data stream, etc. How do you go about figuring out how to parse it, or is that factory sql’s job? Thx.
No, I’m pretty sure that’s going to be your job. 
Off the top of my head, you would grab the raw data in an action item, and then rip through it to get the data youo need. Once you see the raw data, it wouldn’t be hard.
Note that I only mentioned this because you brought up a serial connection. Another way is to gather the analog signals from the devices and gather them up at a central PLC and get them through your existing OPC Server. That might be a better option if you have the right analog devices. But of serial is your only option, I wouldn’t use a PLC.
Gathering them to a central plc was my first guess as a good approach. I’m hoping Colby has a new module in the works for the next factory sql upgrade (due out at the end of the week, probably) that will do just this 
Colby?
If you can bring the analog signals into a plc - that’ll be easiest.
There’s no rule to say that OPC servers have to talk to PLCs - theoretically they can talk to anything. You might want to take a look at Keyware’s U-CON driver, its a configurable serial driver that should be able to do serial-over-ethernet, I think. Once its in Kepware, of course FactorySQL will be able to see it like any other data.
There’s another commercial product, Software Toolbox’s OmniServer (softwaretoolbox.com/omniserver/), which is very similar to Kepware’s UCon product. I have used it with hardware and virtual TCP/IP serial ports.
BTW, Software Toolbox also sells relabeled versions of Kepware, including UCon. (toolboxopc.com/ucon/)
[quote=“MickeyBob”]There’s another commercial product, Software Toolbox’s OmniServer (softwaretoolbox.com/omniserver/), which is very similar to Kepware’s UCon product. I have used it with hardware and virtual TCP/IP serial ports.
BTW, Software Toolbox also sells relabeled versions of Kepware, including UCon. (toolboxopc.com/ucon/)[/quote]
I have used the UCon to read Scales and Barcodes and the OPC Server configuration is every poweful you can create OPC items by parsing the stream based on the data you need. Plus Kepware tech support is create helping you out configuring the UCon driver.
Hi to everyone following this thread. We’re on the verge of figuring it all out, so keep tuned in for details…
If you’re not part of the solution, you’re part of the precipitate.
Henry J. Tillman
We currently have the UCON driver up and running and we are capturing data using FSQL in the database. It was pretty painless as advertised. The UCON driver allows for solicited data capture, which we configured and worked fine, but found that each read had to be initiated by a lab tech after each test. We ended up attaching the device via a Y cable off the printer and configured the driver unsolicited. Now each time they run a test, we write the sample into the database.
I am reading the entire test in as a string, the parsing that string into tags in Kepware. One read, 10 update tags. Each time the tags change FSQL writes a line in the database. The one catch we had was that because we are reading off a printer feed, it takes about 20 seconds for the entire dataset to come in. I could see the data coming in, but it was not updating the tags. I had to change the timing from the default 1000 ms to 30000 ms and it is working fine.
The support tech at Kepware was very helpful and walked me through the initial configuration.
I am currently creating the FPMI screen for the LAB so they can associate the test information from the database with the sample they put into the machine.