Read Two Mux'd Channels

[beavercreek]

I'm trying to perform a CAN Read:Multi-Chan Multi-Samp 1D Wfm.  My channel list includes one normal channel, and two channels that are each are mux'd.  The behavior seems that it will get the first value from the first mux and never get another new one.  The data from the second mux is fine and updated as should be.  I then swapped the channel order in the channel list and the same behavior occurs (ie which-ever mux is listed last in the channel list is the one that gets updates).

I used test panels in MAX to prove that there is nothing wrong with either individual channel.  Any ideas?

System: LV7.0, CAN 2.3.2, MAX 4.1

[beavercreek]

Wahooo!  a breakthrough (of sorts)...It appears this funky behavior only occurs when the number of samples to be collected is greater than Sample Rate/2.  Example 10000S/s I can collect up to 5000 data points with NO issues.  250S/s I can collect 125 samples, etc...and the mux'd channels work fine.  Probably has nothing to do with mux, but would still like to gain the knowledge of problem.

[beavercreek]

Previous post was incorrect.  Should have stated, works properly until samples to acquire exceeds ~2*sample rate.  Also figured out that it was always the higher arbitration ID message that was getting tossed, no matter if it was the first or second one listed in the channel list.  For reference the lower arbitration ID message also has more data modes associated with it, three, and I keep only one.  The higher arbitration ID message has two modes, and again I keep one.

Found a work around, wiring CAN ports 0&1 together and using port one for one mux'd channel and port zero for the other solved the issue.  Obviously for those poor soles with only one CAN port this is NOT a workaround....

Would love to understand this error/behavior, any guesses out there?

[Jason W]

Hey beavercreek,

Can you post your database file so we can investigate this behavior you are seeing?

Thanks,

Jason W.
Applications Engineer
National Instruments

[beavercreek]

Here they are, careful, they're huge...

[DirkW]

I checked the files  and i saw only one channel per mux.  I assume that you use more then one channel per mux normally. Otherwise it would make no sense, because the mux allows you to create multiplexed channels for the same message. And thats the only usecase i know about.

Anyway, attached you can find an example dealing with your channels and i found it works fine. Perhaps your driver needs a update, because we fixed mode depended issues with newer versions.

For your LV 7.0 try  2.3.3. I think thats the latest version for 7.0. Or try a 7.1 version with NI-CAN 2.4 if available.

DirkW

Message Edited by DirkW on 04-06-2007 08:55 AM

[beavercreek]

Modified the vi slightly, and took a couple screen shots, the only difference between the two runs being the number of samples to acquire.

[DirkW]

I guess your complain is the PWM Command channel, which is a steady line in graph 2? It seems this channel is acquiring allways values above 6000? Well i could not reproduce this here with NI-CAN 2.4. Did you check the values in parallel with a second device?

Perhaps you could try LV 7.1 and NI-CAN 2.4?

DirkW

[beavercreek]

>I guess your complain is the PWM Command channel, which is a steady line in graph 2?

Yes, should look identical to graph 1 (ie following the other signal, but at larger magnitude)

>It seems this channel is acquiring allways values above 6000?

To me it seems to have grabbed one sample, (the first one) and never reported any of the new values.  I can kind of prove this by running the vi multiple times and the line will move position on the screen.

>Did you check the values in parallel with a second device?

I have verified the messages are changing with secondary CAN bus hardware/software.  (plus if i reduce the # of samples it will work again)

>Perhaps you could try LV 7.1 and NI-CAN 2.4?

My company is moving to LV8.2 so that should allow me to move beyond the LV7.0 NI-CAN 2.3.2 limitation.  Thanks for trying Dirk!