Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Communication between two programs using shared NI-GPIB

Hello to everybody!

 

We are buying a PC-based device having an NI-GPIB board used by the software to communicate with the external world.

 

Normally I'm expected to use the following architecture:

 

PC With GPIB interface running My software >-----GPIB Cable -----> Device with NI-GPIB Interface running its own closed-source software.

 

Since the Device is Windows based can I move my program on the device?

 

In other words: can the two programs, while running on the same PC, share the same GPIB interface to talk to each other?

 

Thanks in advance for any help!

Marco

 

 

0 Kudos
Message 1 of 7
(5,385 Views)

Interesting question

 

It should be possible to use another GPIB adopter in the same Windows machine and assign different addresses other than the existing one used by the Device Software. In effect you will have two NI GPIB controllers, one is used by the Device Software and another one is used by Custom LabVIEW Software. In this case you will be using two GPIB controllers and assign two different addresses and connect them using a cable.

 

I am not sure if we have any software in market which will emulate virtual GPIB hardware and talk to NI GPIB card using the communication layer in the same Windows machine.

0 Kudos
Message 2 of 7
(5,375 Views)

I wouldn't think so.  I wouldn't think an instrument would be able to have a GPIB controller.  It would only be a receiver.  You might be able to communicate to the instrument software using TCP, assuming you know what ports are available to communicate with.

 

From a security stand point, it is better to leave the instrument alone and just communicate it over a GPIB cable with another machine.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 7
(5,371 Views)

Hi and thank you both for your comments.

 

I had this idea to move my program to same computer of the device reading this knoledgebase:

http://digital.ni.com/public.nsf/allkb/C42CDC77C00E0B8086256E9B0078F887

 

According to this document it is possible for a Program A to communicate with Device 1 sharing the same interface with Program B communicating with Device 2.


I was then curious about the possibility to communicate from Program 1 to Program 2 via GPIB interface.

 

But maybe it is too much to ask the GPIB board to act as a controller for Program 1 and ,at the same time, as a listener/talker for Program 2.

 

I'll let you know any further developement.

 

Regards,

Marco

 

 

 

0 Kudos
Message 4 of 7
(5,362 Views)

I was then curious about the possibility to communicate from Program 1 to Program 2 via GPIB interface.

 

That may or may not be possible (I've never tried it) but it is sort of foolish.  To communicate between applications use an appropriate data transfer mechanism.  a single process shared variable comes to mind. or even a temporary file.   


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 7
(5,336 Views)

I completely agree with you, Jeff.

But the issue here is that one of the applications is closed source and communicates with the world through GPIB.

 


Marco

 

0 Kudos
Message 6 of 7
(5,317 Views)

@MarcoMauri wrote:

I completely agree with you, Jeff.

But the issue here is that one of the applications is closed source and communicates with the world through GPIB.

 


Marco

 


well, that is exactly why HPIB was invented.  Pass CIC! and let the onboard processors take control of the whole system........but MyProcessA to MyProcessB communications ---- that does not work well.  It can be made to work!  Using that bus!

Have you played "Oregon trail" lately?  in the 1960s it was sometimes necessary ,due to the lack of higher level languaguges, to program with the silicone onboaod the instrument in the loop  (and baud rate limitations).  There are much more effective methods today.  Software defined hardware is a "New Technoledgy"  Can you provide a use case?


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 7
(5,290 Views)