FIeldPoint running slowly

[Dave_Thomson]

I've got an app that I've deployed to three other computers before.   The fourth is in a different state and I'm trying to get it running remotely.  Fun.
Anyway, they all have FieldPoint over RS232.  The main differences are that the old computers used W2K and LV 7.x, and the new one is XP with LV 8.2.  The new one also has a USB-to-serial adapter to talk to the FP unit.
The program assembles an array of FP addresses.  Once a second it asks for data from each one, sequentially.  The problem is that the new system takes 200 to 300ms for each FP Read call, so the whole array takes 3 to 5 seconds to get.  On the old system, it ran fine within 1 second.
Any clues what could be causing the slowness in the FP Read?

Thanks,
   Dave

[Graziano]

Hi Dave!
   I've been using RS232 + FP + LV 7.1 + XP for a long time.  What I can report is that both using rs-232 port, or using a USB-RS232 converter performs almost the same.  I've also made, in the past, some tests on 232 port speed (turnaround time), and I never noticed hard differences between using an adaptor (USB to serial) or a 232 slot.  BTW, I'm using "low cost" adaptors, they're just used to debug purposes...

   Have a nice day!

graziano

[Wayne.C]

Dave,

I would start with the USB-232 adapter.  I ran some tests a couple of years ago that showed that the USB adapters are pretty slow when compared to a built  in serial port.  If memory serves a standard RS232 was about 50% faster than PCMCIA adapter.   PCMCIA adapter was 200% faster than USB adapter.  The extra time seems to be burned up in reads and writes to port.  This test was done with a Black Box PCMCIA and a NI-USB-232 adapter.

In my case I worked around it by reducing the # of VISA reads and writes.  You could run a test where you read all the channels on a FP I/O module one at a time and then read all the channels at one time and see if there is a difference in time.

[Graziano]

Hi!
   I guess the problem can be on VISA OPEN and CLOSE, probably system found more difficulties to do such operations, while with write and read I encountered no problem. But I'll check further.

   Have a nice day!

graziano

[Wayne.C]

Dave,

How many FP addresses in array?

[Dave_Thomson]

   Thanks for the ideas.  I don't know whether to suspect the USB-2-serial converter or not...
   Right now there are about 18 FP addresses in the array.  I loop through them and read them each one channel at a time.  On other systems running XP and older versions of LV, this wasn't a problem.  Now it is taking 300ms per channel.  If this is due to the USB-to-serial adapter, then that thing is reaaaaaallly bad.
   There are no explicit VISA opens and closes.  I'm using the FP Read function, so although the FP is on a serial port, I'm not accessing any VISA functions directly.  Who know's what it's doing in the background.
   I haven't used FP a lot, especially recently.  (I wrote this app years ago.)  :The reason I put all the FP channels into an array and loop through them one at a time is because I want the system to be very user-configurable.  I've told the end-users how to use Max to add new channels.  So the program queries the FP database and assembles a list of channels, then uses that list to get the data.  I'm aware of the fact that each module can have an "All" channel, so that a single call returns all the channels in a module.  Is that the main mechanism for getting multiple channels in one call?  Or is there another way to group an arbitrary list of channels into one call?

Thanks,
   Dave

[Wayne.C]

Dave,

I don't think that a VISA call is the only function that will have the extra delay.  I think that each time you access the USB COM port, there is a bit of extra delay and that the way to combat it is to reduce how many times you access the port.  That was why I suggested the FP Read all option.

[Dave_Thomson]

Quick update for the archives:  The client replaced the Belkin USB-to-serial converter (a brand I previously had some confidence in) with one from Cables-to-Go.  The problem disappeared.  Switched them back and the problem reappeared.  Very odd, but it seems definitive that this issue was caused by the USB-to-serial converter.

Cheers,
   Dave T.

[ClintM]

Hi Dave,

Wow, that's good to know for future reference.  I always thought that Belkin was pretty decent, too.

---

I'm aware of the fact that each module can have an "All" channel, so that a single call returns all the channels in a module.  Is that the main mechanism for getting multiple channels in one call?  Or is there another way to group an arbitrary list of channels into one call?

---

You can add arbitrary channels to a new IO Point in your FieldPoint configuration under Data Neighborhood in MAX.  Just right-click on the module >> Create New.  Select your channels and give your IO Point a name and you can call it in LabVIEW.

Cheers,

Clint M

[Graziano]

Hi Dave,
   In my FP system (as serial modules, I use FP-1001, with 4 wire 485), I have shorter communication times, ie I scan  9 modules in 200 ms (144 between digital Input and Output). I communicate with optomux protocol (FieldPoint --> advanced --> serial config palette), at 115200 bps.   I open COM, configure it, and perform read functions. when it's finished, I close com.

   What modules are you using?

   About the USB/serial adapter, I use very low cost ones (Manhattan), and they never gave problems....  of course the problem is the adapter, I was wrong about it. .

   Have a nice day!

graziano