data acquisition CAN bus

[GerdW]

Addition to last message:

In your first post there is no wait function in your loop - it runs as fast as it can. Why do you want to burn even more CPU power by adding a small delay in it?

[Hooovahh]

---

@Trainee123 wrote:

Actually is there a way to loop the while loop faster than 1ms, like 50us? I don't have labview real time module so is there an alternative way to do so?

---

Sure you can run a loop as fast as the CPU will allow.  Of course then you are in software timing and as Gerdw said you will not have consistent results.  This is a problem with ALL software that isn't hardware timed.  As I said before the problem is with your hardware, and patching software is not the right solution.

[Trainee123]

Thank you GerdW and Hooovahh. Actually, the CAN bus interface that I used is able to transmit a CAN frame every 0.1ms. This has been proven when I used the software provided by the same company that enables me to monitor the CAN frame in the CAN bus.

But when I tried to poll the CAN Read function in labview, the fastest I can get without losing any data is 1ms(by placing a 1ms wait function in the while loop). 

When I put 0.5ms in the wait function in the while loop, when I look at the CAN frame data acquired in the text file later, I saw that there data acquired at the beginning and then there are data lost in the middle, and the data reappeared and this continue alternatively. 

Is there a way to bypass this jitter problem in windows?

[GerdW]

Hi Trainee,

Is there a way to bypass this jitter problem in windows?

No.

When I put 0.5ms in the wait function in the while loop

Which wait function are you talking about? The ones coming with LabVIEW don't support fractions of milliseconds…

But when I tried to poll the CAN Read function in labview, the fastest I can get without losing any data

With NI hardware you get a message buffer for each CAN port. It buffers messages and you can read them in blocks or just the current state for each ArbID…

[Hooovahh]

---

@Trainee123 wrote:

Is there a way to bypass this jitter problem in windows?

---

Use a deterministic operating system?  Or use timing based on some other hardware.  As mentioned before, other manufactures of hardware have an internal buffer which hold the messages that come in, and can return them all at once.  I've never heard of a piece of CAN hardware that doesn't have a buffer like this.  Heck the raw transceiver usually has at least two bins for messages.