Machine Connect with VFP9

[qamarzaman]

Hi,

I want connect Lab machine (Medonic M-Series) with VFP9
Just import data from machine.
Is it possible ?????

 

[Olaf Doschke]

You don't connect hardware to software...

I googled it and now know it's a Hematology analyzer. OK. Seems like it's a machine of it's own. With a display and software installed, maybe even a proprietary system, not even Linux.

I'm too lazy to look into details.

If it runs Windows internally you could use VFP to develop apps on/for it.
If it can be connected to a Windows PC you can perhaps control it, import data from it, or whatever. Depends on what driver comes with, what connections it has via LAN, USB, RS232 or any other interface.

Depends on a lot of factors unknown.

If it connects via USB and shows up as a drtive letter you can access, then you can also access it from VFP.

If it connects via USB and has a driver and software to import data from it, then use that. Then it turns to the question, if VFP can cope with the file you get from the data import.

IF it connects via LAN (Ethernet) it depends what you see from it.

IF it connects via RS232 it depends if you get a manual describing commands you need to send to let it send data or however that would work. You could use CommTools to cope with a RS232/COM-Port.

It boils down to the same question about any hardware: Does it come with a driver you can automate, does it create files you could read/process and does it come with detailed info about how to.

And that's questions you should ask the vendor.

Bye, Olaf.

 

[JRB-Bldr]

Since Olaf has already answered many of the ESSENTIAL questions that you forgot to metion in your posting, you need to see if the Medonic M-Series has some sort of 'programming' language in addition to a useable Hardware interface.

If it has a 'language' you should be able to use your VFP application to 'interrogate' it for its data.

Or, as Olaf has asked, does the manufacturer have a Windows API (ActiveX) utility that can be installed and reside on a workstation and which can be utilized by your VFP application to acquire data from the device.

So, in addition to understanding the device's hardware interface capabilities, you need to ask the manufacturer about what software interfaces they have (or don't have) to enable your VFP application to access its data.

Therefore, you have some more homework to do.
Once you have those answers, come back and share those details with us and we will see if we can better assist you.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

I would strongly advise to not mention VFP at all when asking the vendor. That'll most certainly just give you a no, as they won't even know what you're asking for and even if they search their specs and manuals won't find this.

Ask the vendor for technical specs, if you don't get the product specification from their website, and ask them about the software they bundle with it for end users, ask them for possibilities to export data to any laboratory information management system on the market or what they offer to developers. It's very like such devices offer the possibility to export data to a LIMS, because that's the standard for laboratories, not only medical laboratories. And if they wouldn't support that, their device would be very stand alone and of low interest.

As a VFP developer you should know what Fox can do to reach the outside world, you can:
1. Read any file and if needed convert it as needed, if knowing the file structure. In short: You can access the file system of Windows.
This is not limited to CSV files, but htose would perhaps be, what such a system can write out as their export mechanism.

2. Use any functional DLL via DECLARE DLL command, including Windows API, which makes some drivers also usable with foxpro and other languages.
It's unlikely a vendor makes it's device automatable for anyone via such a DLL, such DLLs mostly are for internal usage and their composition and usage mostly is kept a secret.

3. Use ActiveX controls.
If they really intend and support developers adding functionality to their device, to make it a better selling device, then this isn't unlikely, even though ActiveX development is dropping.

4. Ole Automate anything offering an OLE COMServer (both 3 and 4 are based on COM as in common object model)
Again, if they intend and welcome expansions through thir party software devs, this is a likely interface.

5. RS232 ports (COM1,2,3... etc with COM as in COMMunication port)
For lab devices this is still a common interface additional to USB or Ethernet. CommTools is a nice lib coming as a FLL extending the Foxpro language with low level coimmands to set COMport-Settings and send or receive bytes up to high level functions sending or receiving a file via ZModem protocol.

With extensions like the dotnet Bridge of west-wind you could also use dotNET Assembly DLLs additional to functional DLLs.

That's about it. If you miss the mentioning of USB: In the end you don't control USB ports, you either read from a Drive letter, as with a USB thumb drive, and the communication with the device is handled by the OS, or there is a specific driver DLL, ActiveX, etc. About the same goes for Ethernet interfaces, which either gives you a LAN drive or let's you send HTTP-Requests to the device, which you could do with several options from Winsock over Wininet, XMLHttpRequest, WinAPI or Inter Explorer automation.

And as you should know that or at least some of these categories of interoperability of Foxpro, you should look out for something you can attach to via what you know of them yourself and feel familar with. On the other side, if you're bound to use this device and need to cope with whatever it offers, good luck with it, I hope you find some documentation enabling you to get at your data.

Bye, Olaf.

 

[qamarzaman]

Dear Olaf,

Really thank you so much. for your kind information... also thanks JRB-Bldr.

now receive file from vendors. Kindly tell me how to receive data from machine. (with Programming Code)

 

[qamarzaman]

Attach File


4.3 Advanced Setup (Continued)

The instrument is equipped with an output for connection ta a computer (network). The serial output has a male 9 pill DSUB. It fulfills the RS232 specification.
The pinning of the male 9-PIN-PSUB is as follows: (instrument end)

1 Not used
2 TX-OUTPUT
3 RX-INPUT
4 Not used
5 GND
6 Not used
7 CTS-NPUT
8 RTS-OUTPUT
9 Not Used

To comlect to a PC computer that uses a 25 phi RS232 (Female Female) see instructions below:

Cable end instrument (9pin) Cable end PC (25pin)
2 ---------------------> 3
3 <--------------------- 2
5 --------------------- 7
7 <--------------------- 4
8 ---------------------> 5

Connection to a PC using a 9pin RS232:

Cable end instrument (9pin) Cable end PC (9pin)
2 ---------------------> 2
3 <--------------------- 3
5 --------------------- 5
7 <--------------------- 7
8 ---------------------> 8

To select options for sending results and data follow Instruction below:
1 Start by pressing [ADVANCED] from the MENU tab.
2 Press [SETUP].
3 Press [SERIAL SETUP] to enter the serial setup menu.
4 To set Manual Send Mode function select from the following.
0 = None, 1 = Without Histograms. or 2 = With Histograms
5 To select Auto Send Mode function select from the following:
0 = None, 1 = Without Histograms. or 2 = With Histograms

 

[Olaf Doschke]

This in short means COM/serial port connection. Not sure if the sepcified pin assignement is special or needs proprietary cables, but you should get one with the device or from the same vendor.

You can address COM-Ports with VFP, which is most easy with CommTools. Not sure where you'd get this software now, the last foxpro sepcific shop in germany close a few years back. it has c_puts (write a string) and c_gets (read a string) and even higher level functions to write/read whole files.

There still is mscomm32.ocx for COM adressing, reading/writing. Sample code on mscomm32 usage with foxpro is found here for example:

http://support.microsoft.com/kb/140525

The part of the manual you posted is giving a bit of a start, the main info still is missing: Technical COM-Port settings like baud rate, parity, bufsize, etc. And what command string to send to make the device send it's data. For example with electronic rs232 scales you typically send "T"+EOT (end of transmission, typically chr(0)) to let the scal tare and "P"+EOT to let it send the current weight.

Bye, Olaf.

 

[JRB-Bldr]

What you have shown us is the Hardware interface.
Olaf has given you some advice on how your application can 'talk' to it.

What about the Software interface?
Assuming that you can 'talk' to the device across the Hardware interface, there has to be some way to either 'interrogate' the device for its data or have the device send data via Command requests or in some other manner.

That Software documentation should also tell you how the data will be formatted when it is received so that you will be able to utilize it in your application as needed.

Since your attachment will not open I cannot read the documentation.
Regardless, it is YOUR job to read it and tell us about it.

Good Luck,
JRB-Bldr