04-10-2009 01:11 AM
Greetings.
Background
I have two USB-8473 converters connected to each other and connected to a laptop through an external USB hub. The converters are CAN0 and CAN1. The kernel driver nicanpkw.sys is version 2.5.0f0 and the Nican.dll is version 2.5.0.49152.
Problem
A simple test program (attached) fires a NC_ST_WRITE_SUCCESS notification even though ncWrite is never called. I've tried removing and reinserting the USB-8473s.
PLEASE, someone tell me there's a problem with the test program. I REALLY need notifications to work.
Thank you,
Brian
04-14-2009 06:10 PM
Brian,
This may help you.
In NI-CAN manual it mentions the following:
"When communication starts, the Write Success state is true by default.
For CAN, write success means that the frame won arbitration, and was
acknowledged by a remote device."
Here is the link to the manual:
http://www.ni.com/pdf/manuals/370289j.pdf
Regards,
Sammy Z.
04-14-2009 08:00 PM - edited 04-14-2009 08:04 PM
Sammy Z,
Thank you for the reply.
> This may help you.
Unfortunately, no.
> When communication starts...
The test program doesn't write any frames. The callback is made without any attempt to write.
Brian
04-15-2009 05:04 PM
Hi Brian,
Would you please let me know how you see that notification?
Would you be able to take a screenshot of that?
Sincerely,
Sammy Z.
04-16-2009 12:41 AM
Hello Sammy Z,
> Would you please let me know how you see that notification?
ncNotificationCallback is called which increments NotificationCalls. ReallyBadNews is also incremented indicating that either NC_ST_READ_AVAIL or NC_ST_WRITE_SUCCESS is set. Given the fact that the other node never sends a frame and using the debugger I can tell that NC_ST_WRITE_SUCCESS the bit that's set.
> Would you be able to take a screenshot of that?
Should be attached.
Please don't spend much time on this problem. I've uncovered another much more serious problem with "write success" notifications. The simple fact is that I'm not going to be able to use it.
Thanks,
Brian
04-16-2009 07:36 AM
As mentioned in the docs and quoted by Sammy Z, NC_WRITE_SUCCESS is a state, not an event. Think of it as a state machine... There is the NC_WRITE_SUCCESS state and there is a different state, we can call it X.
NC_WRITE_SUCCESS state indicates that the transfer mechanism is idle. If any transfers had been queued up, they have been transmitted successfully on the bus.
X state indicates that the transfer mechanism is busy, or that the last transfer (if single-shot TX is true) didn't transmit successfully on the bus.
The transitions are as follows:
pon -> NC_WRITE_SUCCESS
ncWrite transistions from NC_WRITE_SUCCESS to X
tx complete and write queue is empty X to NC_WRITE_SUCCESS
tx complete and write queue is not empty X to X
tx failed X to X (typically, this will get retried until write is successful, but it may never be successful)
The notification is not based on a transition, but based on being in a state. At pon, you are in the write success state - if it helps, you can rename this state in your head to be transfer mechanism idle - if that helps to realize that you are in this state even if you have never sent a frame across the bus.
After writing a frame, you will go back into the NC_WRITE_SUCCESS state once it is transmitted completely - which is, what I guess, you want to see, so you would be best waiting until after a write to enable the notification.
04-16-2009 12:59 PM
Guru,
Thank you for the reply! Your explanation added much needed clarity.
Unfortunately, I've discovered that the notification mechanism behaves incorrectly when warnings occur. I won't be able to use it for NC_ST_WRITE_SUCCESS.
Brian
04-16-2009 01:01 PM
04-16-2009 01:20 PM
"Warning" as National Instruments uses the term: the frame was successfully sent but something bad happened.
For my testing, I briefly disconnect the CAN cable. This causes a CanWarnCommNoAck warning.
- Brian
04-16-2009 01:26 PM
That is not exactly the case.. "Warning" means that the bus is in a disrupted state it has nothing to do with the data transfer, per se. CanWarnCommNoAck means that the frame was NOT sent successfully.. The CAN controller will continue to retry the frame until it is successfully sent (unless you have single-shot TX enabled, which I don't expect or recomment).