How to deal with XNET Write and Read in one loop?

[DanielDu]

  I just find that if the read function was placed behind write function in one loop, I can not get any reponse at all!

  For example, I send ID=0Xb000011 out, the response should be 0xa000011. However, I can not get that.

    >>('0xb000011', '[0x04, 0x00, 0x11]')
    <<('0xa000011', '[0x04, 0x00, 0x11, 0x30, 0x04, 0x01, 0x16, 0x00]')

  I know if write function and read function are placed two loop in parallel, it will be ok, but I don't want do like this, it makes block diagram looks some of mess.

  Could anyone tell me how to capture the response without any miss in just one loop. Thanks!

[Hooovahh]

Okay both sessions can exist and one should not affect the other any more than in the intended ways.  Like if you change the baud rate on the write, the baud rate on the read changes, because they share the same hardware interface.

Other than that I'd say it has to do with the device you are talking to.  I'd recommend putting an independent CAN device on the bus to log raw frames as they happen.  Then you can see how data is actually sent from both the XNet hardware and the device.  In this case I see no reason why this wouldn't work, assuming the UUT actually responds as you expect.  Have you tried logging all raw frames being read?  Possible build an array with the concatenate terminal out of the while loop, with some kind of timeout or stop control so it doesn't stay in that loop forever.

[dkfire]

How fast are your unit able to reply? within 1ms?

I would add a timeout value that is non-zero.

As it is now the read function will read the CAN buffer as fast as it can and return maximum one CAN frame. If nothing is in the buffer yet, you'll get a empty array.

[Hooovahh]

This is likely it now that I look closer.  You don't have a timeout wired in your read, so it will return as fast as it can, even if there are no frames to read.  You should wire a constant of something waiting for that single frame.

[ben64]

I agree that the timeout value of zero is likely to be the reason why you read an empty frame. Do you get an error? Do your while loop only iterate once?

Ben64

[DanielDu]

Hi all,

     Thanks for all of your suggestion.

     Actually, It's my fault. above block diagram works ok with timeout setting to 0.  Now question is why it works? because the responsed frame happened 1ms later, I have try timeout to 0.5ms 0.1ms,1.5ms, a timeout error will happen on XNET Read.vi

   

[Hooovahh]

I'd recommend setting the timeout to much longer than the expecte time.  Say 10ms, or 100ms.  If the reply comes in 1ms then  you have nothing to be worried about the function will return in 1ms.  But if the module screws up, or if there are higher priority messages on the bus then it is possible it will be greater than 1ms.  Of course this doesn't explain why it would work with no timeout.

[DanielDu]

Hi Hooovahh,

    I always have a question about XNET read function, it seems like that all read vi doesn't support buffered read, don't like DAQmx which can first store received data into a buffer and then pending to be read. 

    No matter how long time out I set, the timeout error always happen during Read. If XNET read support buffered reading, I can always get the reply and don't care about time out settings. 

 BR

 Daniel

[dkfire]

What happens if you add a delay between the write and the read? A delay of 1 or 2 ms.

Is there still a timeout?

[DanielDu]

Yes, timeout always comes up except set it to zero.