FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

RT Ethernet!

Hi, evry!

The problem is the following.
I have a system wich consists of Host (WinXP) and RT controller (8186). Every soft is 8.0-versioned. They're connected together in a "pair-to-pair" way (with cross-cable). The load on half-duplexed Ethernet is quite heavy sometimes.
And, sometimes the connection gets lost at all (ping of my RT controller is no use), while local 127.0.0.1 pings OK. And after that the only way to wake system up is to reboot RT controller:(.

How can I get rid of this kind of RT Ethernet behaviour?

Thanx in advance!
0 Kudos
Message 1 of 14
(11,745 Views)

Dear Sharonoff,

It is very strange that you are completely losing connection sometimes and you have to reboot the controller. I would encourage you to format your controller and reinstall the software from MAX.

Half duplex connection is supposed to speed up the traffic between your PC and the Real-Time target when using a crossover cable. Make sure your settings for the remote RT target and your Host PC network card are set to 100Mb Half duplex. For the remote target, you simply click on the icon in MAX, and then click on the "Advanced Ethernet Settings" button. Use the "Media Mode" drop down menu to select the connection mode.

For you Host PC network card, go to Start>Settings>Network Connections>Local Area Connection. Then click on Properties. Then click on Configure>Advanced>Speed & Duplex. Select 100 Mb Half from the drop down menu.

Hope that helps!

Kalin T.
0 Kudos
Message 2 of 14
(11,700 Views)
Thanks a lot, Kalin!

Still, the question is on.

Why doesn't my system just hang for a while instead of disconnecting Ethernet at all?

The problem is ocasional. It's period is proportional to the quality of cable layout, you know.
But... In the case of collisions RT Ethernet conroller should just hang up for a while, as far as I comprehend and shouldn't break up at all.

And one more thing for you as application engineer. The flag "Halt system If TCP/IP fails" in MAX - what does it intended for?

Anyway, thank you very much.
0 Kudos
Message 3 of 14
(11,681 Views)

Hi Sharonoff,

Here is the description of Halt system if TCP/IP fails

"Enable this checkbox to stop the LabVIEW Real-Time Module if the network connection fails when you boot the remote system. If you clear the Halt system if TCP/IP fails checkbox, LabVIEW RT starts and runs startup applications you created, even if TCP/IP fails when you boot the system.

 Note:  DHCP failure is considered a TCP/IP failure. "

In other words, it should only affect your Real-Time Module when it initially boots up. You can try running your application with the box checked and cleared.

As I mentioned in my previous message, there might be something wrong with one of the installed drivers on your Real-Time controller, specifically the driver for your Ethernet network card. Formatting the controller would be the first step I would take.

Please let me know if you continue seeing the error after formating the RT controller. Also provide me with some information on what kind of traffic you observe between your PC and your RT controller. More detailed information on your application will be helpful to pinpoint the problem..

Hope that helps!

Kalin T.
0 Kudos
Message 4 of 14
(11,593 Views)
First...
Thanx for a'tention, Kalin!

...And as your suggestions are about...
I didn't managed to make a formatting of a controller, but geathered some information concerning it's load.
I would highly appreciate if you would look into the following thread:

http://forums.ni.com/ni/board/message?board.id=170&message.id=221796&query.id=25150#M221796

...all the more, the question has noth to do with FieldPoint.

The traffic information you mentioned is there.

I'm looking forward to your comments.
Thank you in advance.
0 Kudos
Message 5 of 14
(11,067 Views)
Sharonoff,
 
I looked at your screenshots. The CPU usage is OK. You memory usage is OK as well, it is pretty low actually. The LabVIEW users who commented on your problem thought that you might dynamically allocate more memory with every iteration of the while loop. I don't know within what time you took those screenshots, but I can see there is a slight increase of memory usage from 46367 KB to 62873 KB (in the top two pictures). Still this a very small percentage of the total available memory.
 
Please follow all of my suggestions, then the suggestions of the LabVIEW users to see where your program hangs. You should also aim at reproducing your problem with a very small piece of code in which it will be easy to pinpoint the problem. Just run some of the examples that come with LabVIEW RT. If you need more help after you try all of our suggestions, please post more detailed information about the architecture you are using for your program. We do not know what you are doing. Make sure you have Wait and/or Wait Until Next Millisecond Multiple VIs in your while loops. If you don't put your while loops to sleep they tend to use the CPU to the MAX prevents the network communication process to use any CPU time.
 
Hope this helps!
Kalin T.
0 Kudos
Message 6 of 14
(11,047 Views)
Thanx a lot !!!
0 Kudos
Message 7 of 14
(11,045 Views)
Hi, Kalin!

At last, I came to the following conclusion:
the reason for "plugging" Ethernet on RT is Timed Loops.

To begin with... All the experiments were made on absolutely fresh 8086PXI controller with 8.0 LV RT version. No NetworkSharedVariables were used.
I've made a comparison of RT System behavior after running two identical VIs - one with Timed Loop and another with this Timed Loop replaced with regular while loop with the same (and even harder) time restrictions. (See pic s10.jpg attached.) And...

After EVERY start of "TimedLoop.vi" system "hangs up". "Pinging" of it gives strange responses about ~2500 ms of delay and, the most common case - "The waiting time for request is elapsed (5s)". And, again, the only way for me to waken system up is controller reboot.

As the "RegularLoop.vi" is concerned, it's behaviour is much more predictable and safe;) - system just let loop iteration to lag and that's all.

I've made a number of experiments starting "RegularLoop.vi" and "TimedLoop.vi" and the results were everytime the same as described before (and shown in the pic)!
...and it looks just like... even when the load on CPU is about "only" 60-70%%, the probability to "fail" Ethernet gets very high!

So.. How can I make TimedLoops and Ethernet to work together on RT?

Thanx in advance.
Looking forward to !!!
0 Kudos
Message 8 of 14
(10,979 Views)

Hi Sharonoff,

I did not know you were using LabVIEW FPGA. Your timed loop shows that you are using a 1MHz clock and your wait time is 2us. I can't really tell what resolution you are using in the regular loop - millisecond or microsecond? Did you try setting different wait periods just to see how your loops would respond to that?

I think you are not giving enough sleep time to your Timed Loop, so the CPU does not allocate time for any other process besides your Read and Write operations. Hence, your communication process fails.

Also you should consider special architecture.
Host VI (on PC)

Noncritical loop VI (on RT) - it handles all communication with the Host VI on the PC via Network Shared Variables or other communication techniques.
FPGA VI (on RIO) - handle al I/O and sending data back to the Noncritical loop VI.

Hope that helps!

Kalin T.
0 Kudos
Message 9 of 14
(10,933 Views)
Thank you for your attention!

As far as loops are concerned - the resolution of regular loop is microsecond either.

And... You see.. The Ethernet communication starts only after all the VI activity (including loops) is over (the CPU load gets about 15%-25% again wich is due to the "arbitrating" Timed Loop that is almost always in running state and has lower priority compared to other Timed Loops. Then Another VI is initiated via Ethernet and so on.

It is still so vague for me - why even after, for instance, five seconds of hardest CPU load (100% of system resource) Ethernet just "dies" instead of working as before.
Don't get me wrong but it looks like some misfunction in RT core - it can't back to it's normal condition. Maybe system tries to "repair an omission"? Suppose this behaviour is worth while workabout for NI 😉 !

Well, anyway, Kalin, thank you very much.
0 Kudos
Message 10 of 14
(10,918 Views)