serial port snooper

[smercurio_fc]

---

James W wrote: 

I don't need to be able to communicate with the port, I just need to be able to see what is going through the port (in both directions at the same time would be great) without a H/W solution.

---

Neither PortMon nor NI-Spy require any additional hardware. I don't quite see why you don't want to use these. They're very simple to use and "off-the-shelf" solutions that would not require you to have to write any additional code, as you would need to do using the Action Engine idea.

[James_W]

Ahh sorry Ray,

I seem to have confused you.

To answer your question:

 - Yes I know what an AE is - I have also read Ben's nugget.

To elaborate and try to help with the confusion I am causing. 

I write all my drivers for communications with instruments as AEs....

so whilst I am use AE "Serial Port Communicate.vi" to talk to a device, I want to monitor the traffic with another method inside LabVIEW - another AE would do - in this case I would call it "Serial Port Monitor.vi" and it would be able to see in real time all the traffic created by "Serial Port Communicate.vi" and recieved at the PC port that "Serial Port Communicate.vi" is connected to.

- Like "Serial Port Communicate.vi", "Serial Port Monitor.vi" would not be hardocded to one port.

I was hoping to create a generic function outside of my AEs that I could use to log any port doing any thype of comms protocol on the PC (within reason).

James

[RavensFan]

If you are alreayd funneling all of your serial communication through an action engine (which is what I do), then it should be easy enough to add a logging functionality to that action engine.  Even for on-screen monitoring, it could call a subVI dynamically and let the action engine update a string control on that subVI.

Trying to code you own snooper in LabVIEW that doesn't otherwise interfere with your code is going to be pretty much darn near impossible, in which case you should stick with NI-SPY or Portmon.

[Ray.R]

---

Ravens Fan wrote:

Even for on-screen monitoring, it could call a subVI dynamically and let the action engine update a string control on that subVI.

---

That's pretty much what I had in mind.

I didn't realize that you were already using an AE for serial communication.  I never thought of that.. 😮  I typically have my "special" vi's for serial communication.

[James_W]

Looks like I'll have to examine my generic driver architecture to make logging easier.

Using an AE for Device Comms means you don't have wires crisscrossing the block diagram and you still have the correct Port reference open in the SR (you can also check for duplicate sessions and handle them easily) Error logging for one device in 1 place, driver is a self contained module so it is portable from project to project and contains all the commands I need. (Easy for quick setup)

Please feel free to point out the downsides to using an AE for Instr Comms - (apart from the requirement to adapt the AE slightly if more than 1 device of the same type is present in the system.)

James