Loop drops when connected wireless (NI 9191)

[F.Willems]

Hi,

I cannot figure out why a NI cDAQ 9191 chassis has connection drops when connected wireless and works

perfectly when connected thru LAN.

I wrote a little test VI to check the connection accuracy. The chassis has a NI 9375 I/O module plugged in.

A Moxa AWK3121 is used as wireles access point. What I do is check 5 digital inputs and control 3 digital outputs.

The outputs are continuously placed on/off at a different rate. I use an event loop and a main loopt that communicates

to the chassis at a loop rate of 10ms.

 

The chassis, laptop and Moxa A.P. are all close together on my desk. The Wifi signal is excellent.

Now, the code i written is probably not optimal.

But...  If I start with connecting the chassis with a LAN cable to my laptop, Wifi Disabled, Linked Local. The communication is perfect.

No drops between the loops and the real time.        

No communication errors. Runtime was 52 minutes.

Second test. Connected the chassis to the Moxa A.P. with LAN cable. Laptop connected wireless to the Moxa A.P.

Chassis still in Link Local. Ik can access the chassis in MAX. No problem.

When I run my test, I immediately see loop pauzes. After one minute there can be already a difference of 20 sec.

between calculated looptime and real time. Sometimes the active light on the chassis goes off and on.

When the active light is out, the loop is on hold. (Wich is normal as I assume the DAQ VI's are waiting for response.)

After appr.10 minutes the error -50405 "No Transfer in progress because transfer was aborted by client".

If I look at the timings there is already a difference of more then 5 minutes between the loop timing and the real time.

As last I tested with the chassis and the PC connected wireless to the Moxa A.P.

I did not get the -50405 error, but again loop drops. After 10 minutes there was a shift of 2 minutes.

Has anyone experience with wireless connections with the NI 9191 chassis?

Can I change my code? Did I mis something? (I'm a newbie to Labview)

Any help or suggestions would be appreciated.

Thanks in advance.

Frankie.

Labview 2014 SP1 (32bit) on Windows 7 Enterprise (X64)

Chassis and Moxa all updated to the latest firmware.

[antsundq]

From what I understood of your code, the first loop is only used to initiate the program and the second is to monitor the time drift you are experiencing. Is this correct? 

If you use the wireless connection you will be limited by the speed of communication between your devices. Obviously, ethernet is much faster and more reliable than a WIFI connection, even if the distance is very short. In the second loop you are using a loop time of 10 ms and then a case structure running in parallell with this timer. If the case structure takes longer than 10 ms, the loop time will be limited by the code in the case structure. In the case structure you are communicating with the instrument, and I would guess that 10 ms is to little time for all the signals to get sent and received. Is the problem still there if you increase the loop time to e.g. 100 ms? 

You could try doing a ping test by opening a comand prompt and typing "ping " followed by the IP address of the unit. What response times do you get? 

/Anton

[mikeporter]

How many other WIFI access points are there in the area? How far are you from this one?

Mike...

[F.Willems]

Hi Anton,

Thanks for the intrest.

Indeed. The first loop is an event handler and initiate the task.

If I increase the loop time, it is even worse.

This is the ping result :

Pinging 192.168.127.253 with 32 bytes of data:
Reply from 192.168.127.253: bytes=32 time=1ms TTL=64
Reply from 192.168.127.253: bytes=32 time=1ms TTL=64
Reply from 192.168.127.253: bytes=32 time<1ms TTL=64
Reply from 192.168.127.253: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.127.253:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

Looks good.

It it not only the loops stalls that worries me, connection loss with the chassis, resulting in

an error is a bigger problem. For now we run the main Labview application connected

with a LAN cable.

Regards,

Frankie

[F.Willems]

Evening Mike,

There are 6 - 7 other hotspots available.

The Moxa stands on my desk.

Appr. 1 meter away.

Thanks.

Frankie.

[mikeporter]

If they are all trying to use the same channel that could be a lot of interference.

Mike...

[billko]

I am not clear on whether you are connecting the two together "in it's own little network" (which implies "router" and not "AP") or if you are connecting to the LAN through the wireless device (in which case it is entirely appropriate to refer to the wireelss device as an "AP").  Your last post about hot spots is what confused me.

But as you said, the biggest worry is the active light.  Try using a different router/AP.  I've seen routers overheat and reset themselves before due to inadequate heat sinking.  i.e., Someone (not me, I swear!) dropped the AP and knocked the heat sink off the chip.

As for the delay, if you are indeed using the Moxa as an AP, are you sure you're connecting to your AP?  If you're connected to a hotspot instead, your throughput will be at least halved - and maybe even 1/4 bandwidth if your AP happens to have connected to a different hotspot than you did.  If you are using it as a router, try differnt bands or channels to see if you can get around any interference your company wireless network might be generating.

In general, conclude that wireless isn't the best way to connect test devices together.

[F.Willems]

Hey Mike,

I tried all 3 channels that should give the smallest interference between channels. (1 - 6 - 11)

Knowing channel 6 is default on almost all wireless devices, I see a small improvement in drops.

At least no connection loss after a 10 minute run. But still 2 minutes of stalls.

Not acceptable for digital I/O.

For critical (safety) electrical I/O apps in the future we will use cRIO I think.

Thanks,

Frankie

[F.Willems]

Hi Bill,

The Moxa is configured as an Access Point and I am connected to that AP only.

The Moxa's are brand new. I have tried with both of them.

I've tested on different channels, with small improvement on channel 1 and 11.

As I stated in previous reply, I think using a cRIO will be more reliable.

Thanks,

Frankie.

[antsundq]

Hi Frankie,

As many other have concluded, using WIFI is not ideal for time critical measurements and I would not recommend it for safety critical applications. For simple data aquisition and logging the situation may be another. 

The problem, as I see it, is that you are actually running the loop on the development computer and the loop performance will be bottlenecked by the data transfer over the wireless connection. For safety critical applications using a cRIO, as you suggest, would be a superior alternative since the program is actually running on the cRIO and the actual data transfer to the host pc will not limit the data acquisation. In addition you can use a real-time operating system for superior determinism and you can also take advantage of the FPGA. 

/Anton