Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
CAN initialization
Brunotte
Member
04-15-2005 11:52 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hi,
I'm currently doing some basic testing of a device's CAN functionality including a test with various baudrates. For this purpose it would be nice to have my LabVIEW program initialize the NI-CAN-Controller with every start of the program, because it is possible that the device does not acknowledge and NI-CAN repeats sending the message forever.
The Frame API allows the performing of a reset via the CAction vi. However, using this vi doesn't seem to do anything.
If the NI-CAN hangs somehow and does not allow the execution of CConfig for example, calling CAction-Reset _before_ the CConfig vi still returns an error. The only way out is to reset the whole System.
Furthermore I have been unable to sucessfully clean the receive buffer of the NI-CAN. Currently I am doing a CConfig, COpen, CAttrib with "Read Entries Pending" and put its result into CReadmulti. This is supposed to clean the buffer, isn't it?
The system is a PXI-RT 8186 with a 8461 series 2 controller.
Anyone got advice?
I'm currently doing some basic testing of a device's CAN functionality including a test with various baudrates. For this purpose it would be nice to have my LabVIEW program initialize the NI-CAN-Controller with every start of the program, because it is possible that the device does not acknowledge and NI-CAN repeats sending the message forever.
The Frame API allows the performing of a reset via the CAction vi. However, using this vi doesn't seem to do anything.
If the NI-CAN hangs somehow and does not allow the execution of CConfig for example, calling CAction-Reset _before_ the CConfig vi still returns an error. The only way out is to reset the whole System.
Furthermore I have been unable to sucessfully clean the receive buffer of the NI-CAN. Currently I am doing a CConfig, COpen, CAttrib with "Read Entries Pending" and put its result into CReadmulti. This is supposed to clean the buffer, isn't it?
The system is a PXI-RT 8186 with a 8461 series 2 controller.
Anyone got advice?
biker2000
Active Participant
04-15-2005 04:35 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hello Brunotte,
It almost sounds like as if not all handles/references are closed properly.
For example, if you configure and open a CAN port, perform some actions with that port and then stop the VI with the ‘Abort’ button, so that the ncClear VI is not called, the handle handles/reference to the port will still be valid and the port still running/active. Calling another ncConfigNet on that port will then cause errors like 0xBFF62007.
On Windows, this is a bit easier to deal with as you can just close all open VIs (and, if necessary LabVIEW itself) to force the NI-CAN driver to invalidate all references and stop the CAN port, but unfortunately this is not possible on LabVIEW Real-Time.
I guess that this is the main problem. Once there are no more unclosed references, the problem with the ncAction (Reset) should disappear, thus you might not need to clear the buffer with the ncGetAttr (Read Entries Pending) + ncReadNetMult combination any more.
Regards,
-B2k
It almost sounds like as if not all handles/references are closed properly.
For example, if you configure and open a CAN port, perform some actions with that port and then stop the VI with the ‘Abort’ button, so that the ncClear VI is not called, the handle handles/reference to the port will still be valid and the port still running/active. Calling another ncConfigNet on that port will then cause errors like 0xBFF62007.
On Windows, this is a bit easier to deal with as you can just close all open VIs (and, if necessary LabVIEW itself) to force the NI-CAN driver to invalidate all references and stop the CAN port, but unfortunately this is not possible on LabVIEW Real-Time.
I guess that this is the main problem. Once there are no more unclosed references, the problem with the ncAction (Reset) should disappear, thus you might not need to clear the buffer with the ncGetAttr (Read Entries Pending) + ncReadNetMult combination any more.
Regards,
-B2k
sutun
Member
09-22-2005 03:06 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
what is the meaning "-B2K"?
Thanks!
