CAN timing issues

[Holroyd]

HI all,

I'm working on a project to control an Industrial drive over CAN (CAN Open to be specific).  I am trying to send and receive messages at regular intervals of 100Hz.  To achieve this I have used parallel while loops (after the CAN initialisation); one writes the CAN messages using the 'ncWriteNetMulti.vi', writing an array of four messages, the other loop checks for and reads messages using the 'ncGetAttributes' and 'ncReadNetMulti.vi'.  The program also includes an Event Structure within a separate loop, in order to handle user interface interactions.

My issue is that the timing of the Send message loop seems to be a bit irregular, I have set the operation of the loop using a 'Wait until Next ms Multiple.vi' to 10ms.  However when I analyse the messages being sent on the CAN bus there seems to be quite a range between messages; varying from 7 - 13ms mostly, however there are a few with 18 - 25 ms seperations between messages. These large gaps between messages usually cause the drive communications to fail.

I understand from this thread:  http://digital.ni.com/public.nsf/allkb/859DA6BB71B8A84F86256B3A0071141C?OpenDocument  that LabVIEW timing SHOULD be +/- 1ms when running on XP (like I am).  I've got a few theories (possibly clutching at straws) as to why the timing is so loose, but would like some feedback on the points from the experts as to whether these are valid or there is something else amiss.

1. The laptop I've been using has an Encrypted harddrive.  This obviously slows down read / write to HDD, however I would expect that the program be loaded into memory when executed and thus not be effected by this at runtime. Fair assumption?  (I'm also in the process of 'acquiring' an unencrypted computer to rule out / In this theory).
2. The laptop spec is too little for what is being asked off it.  I've killed any non Essential programs running to try and speed this up, but not had much success.  The CPU is typically running at <10% capacity (according to the task manager window) so doubt its not up to the job. (With the unencrypted laptop I'll also get a clean install of XP so should remove any problems). 
3. My assumption that LabVIEW can run +/- 1ms is Wrong.  Again this is supported by NI above.. So I think unlikely.
4. My programming technique is poor leading to execution of the loop taking in excess of 10ms.  I didn't think my programming was THAT bad, however any comments on improving my coding techniques are more than welcome.
5. Also built an exe version of the program to see if that improved performance.  It didn't seem to do anything noticeable.

Any comments much appreciated, code attached below. 

Thanks in advance. 

Mark

NI LabVIEW 2010 Full Development System

[Taki1999 · Accepted solution]

I think the issue is that you need determinism and not necessarily accuracy.  The Windows timer will happily kick back a tick count which is accurate to 1 ms, but it doesn't enforce deterministic loop timing.

If you really need determinism, I think you have to go with RT.  If you have to stick with XP, you might consider using a timed loop structure and use some sort of an error handler for when the loop finishes late.

Another option would be to configure periodic messages which use the CAN Hardware timing instead of SW timing.  I know you can do this with NI-XNET but am not positive about NI-CAN.

[nathand]

---

@Holroyd wrote:

My issue is that the timing of the Send message loop seems to be a bit irregular, I have set the operation of the loop using a 'Wait until Next ms Multiple.vi' to 10ms.  However when I analyse the messages being sent on the CAN bus there seems to be quite a range between messages; varying from 7 - 13ms mostly, however there are a few with 18 - 25 ms seperations between messages. These large gaps between messages usually cause the drive communications to fail.

---

The occasional large gaps are normal when using Wait until Next ms Multiple.  You may want to use a simple Wait instead.  Wait until next ms multiple will skip periods if it can't run within the given range.  If you have it set to 10ms, and the next time it executes it's been 12ms, it will wait until it reaches 20ms before continuing because that's the next 10ms period.  This leads to the ~20ms jumps that you're seeing.  By comparison, Wait simply waits until at least the specified amount of time has passed, then continues execution.

[Holroyd]

Taki1999,

Thanks for the reply.  It seems that a deterministic solution was just what was required to get the job done.  I think a RT solution would be ideal, but Xp and a timed loop structure seems to be close enough!

Thanks again,

Mark

[estradjm]

How do you use the Hardware timing with XNET? I am having an issue of just not being able to use the stream output with an array of frames, three which go at 500ms and one which goes at 100 ms. All the frames are being transmitted at the same time, and not even at the rate of either 500 or 100 ms. I am not sure what is going on or why XNET isn't handling anything for timing correctly.