timing on RS-485 bus

[Ben]

Since  the C# version works, try using Portmon to spy on the data packets then copy what you find to the LV version.

Ben

[DavidBoyd]

Ben,

Do you have your hands on a copy of Portmon that runs under Windows 7?  I've never been able to get it to work (64 *or* 32 bit version of OS, I think).  Would love to hear if/how.

Jeff,

Yes, if you can get me any info on the device model (I'm ultimately looking for a PDF describing the interface hardware/protocol/command set etc), maybe I can crank out a little test code.

Standing by!

Dave

[JÞB]

---

@Ben wrote:

Since  the C# version works, try using Portmon to spy on the data packets then copy what you find to the LV version.

Ben

---

Portmon does not support 64bit OS's

[Ben]

---

@JÞB wrote:

---

@Ben wrote:

Since  the C# version works, try using Portmon to spy on the data packets then copy what you find to the LV version.

Ben

---

Portmon does not support 64bit OS's

---

Ok, so has anyone heard of another similar package?

Ben

[Ben]

NI IO Trace is worth trying out. I belive it replaced NISpy and as long as you are using VISA... it may work.

Ben

[Wayne.C]

Jeff,

Based on the scope image I would say that the instrument is responding very fast for a RS485 instrument.  Too fast for 2-wire mode.  2-wire mode requires that the transmitter switch modes from RX to TX and vice versa.  This is usually done by detecting a start bit and timing out after the stop bit/last transition.   I would expect a response no faster than 1-2 mS.

[JThorus]

Thank you all for the responses!

Ben,

I like the idea of examining the data packets while running the C# application. I launched the portmon application and it simply reads Not Connected at the top of the pane with no options for 'Capture' Events or Ports. I am running Windows 7 64-bit operating system so this makes sense anyway. Is it possible to examine the data packets while running the C# application, AND with NI I/O Trace?

Wayne,

My co-worker who wrote the C# application indicated the instrument response was very fast. However since his application works fine (on my machine) given the wiring and setup I am using, I think I should be able to get something working in Labview. My Labview application sets both the ASRL End Out and ASRL End In to a carriage return termination character per my instrument documentation. Maybe the VISA functions aren't capable of running as fast?

I now have the C# source code; I wouldn't be comfortable posting it on here but might be able to PM someone if they are really interested and wanted to take a look at it. I have zero experience with any of the C languages so could use some help there. It is very tempting to try to reverse engineer that application since it works!

Dave,

Will send requested materials later today.

Jeff

[DavidBoyd]

Jeff,

Instinct tells me that there is no issue with response speed.  You're running at 9600 baud, which is glacier speed by today's standards.

Unfortunately the NI-Trace utility (formerly NI-Spy) won't capture calls from a third party app talking to third party hardware.  Sadly, Portmon, which was a great free util from the SysInternals guys, now long since part of Microsoft, has not been updatedd to run under W7 x64.

At this point I'm hoping to get my hands on some documentation and send you a quick 'n dirty VI as a launching point.  This is NOT my first experience with 485 two-wire.

Dave

[RavensFan]

Don't mess with the ASRL End IN and End OUT settings.  When you need to send a termination character, just put it explicitly in the command you are setting.  Send $3DI\r   Not just $3DI.  It is easy enough to code in, you know for sure it is going, and you aren't dealing with any back end crap of relying on VISA to do your work for you.

[DavidBoyd]

I'm going to have to respectfully disagree with you here.  You absolutely SHOULD use the END IN functionality of VISA to your advantage (for instruments/devices which support a single-character terminated protocol) because it alleviates a lot of the nonsense of polling for characters at the port, reading partial messages which then must be concatenated, figuring out your own timeouts in loops, all of which are major pain points especially for neophyte developers.  And I would strongly suggest that application-level programming SHOULD NOT concern itself with adding its own outgoing termination.  There are legacy reasons for this as well - where an instrument can be accessed through more than one interface (serial vs. IEEE-488), it allows you to abstract some of the interface particulars out of your driver level code.

I absolutely prefer to let VISA do the "back end crap", which it does so well.

Dave  (waiting for a REALLY interesting side conversation to start, now.  And RavensFan, I have the greatest respect for you as an active participant here - just so that's clear).