A task containing a single global NRSE ai channel thinks it's differential!

[probably]

Help, surely this is a bug (either in my brain or in labVIEW!).

I'm running DAQmx on a PCI-6229 m series DAQ device, SHC68-68-EPM cables and the CB-68LPR break out PCBs.

I'm measuring ground referenced signal sources of a few volts in amplitude, some of which share a common ground and I am therefore using NRSE measurements on those to preserve free slots.

I've set up a global channel called ILD1 as dev1/ai0 set as NRSE. The connection tab on MAX gives the connections I would expect:

signal: pin 68 (ai0)

ground: pin 62 (aisense)

When I run the test panel for the global channel, I see exactly the measurement I expect so this works fine.

I have then set up a task containing this global channel (and no others). The task seems at first to recognise this as being NRSE (having inherited this from the global ILD1 settings). However, if you look at the connections tab, the connections are now different:

signal: pin 68 (ai0)
ground: pin 34 (ai8)

Running the test panel on this task gives a voltage that floats towards a maximum value. This is consistent with the fact that the task seems to think it's now doing a differential measurement, but I have not connected ai8 and so this input is floating.

So the question is how can the global channel be NRSE (which I want), and a task based solely on this end up as differential? How can I fix this to preserve as many ai pins as possible (e.g ai8 would be useful for something else!)

Thanks

[probably]

Further to my previous post, I have found a discussion here that sheds some light on the problem. It would seem that the tasks in both MAX

and LabVIEW default to the differential mode of AI.

What's even more bizarre is that a task based on a single global NRSE AI defaults to differential in MAX (even though the input configuration appears as NRSE in the greyed-out box).

Would anyone like to explain the logic behind this? What's the point of carefully defining global channels in MAX to use in different tasks only to discover that you have to reconfigure them in LV? Doesn't that kind of defeat the whole purpose of MAX? In fact, it seems to be even worse than that, as you can get really confused how to wire your hardware because of this behaviour (global channel and task based on the global channel give different wiring schemes), and get confused if your hardware is actually working.

One of the contributors in the link above was concerned about people messing up his configuration in MAX so thought that it might not be as bad an idea as initially appears. However, you can export your configuration from MAX and reload it to prevent this problem. Similarly, anyone can mess about with your code if you don't protect it, so it's six or two threes. I thought the whole point was to abstract the design of channels out of the code as much as possible to make it a more pleasant experience?

Comments from NI designers welcome.

[Dennis_Knutson]

Even though you posted in the wrong forum, I'll answer your question since I'm the one that said I like the way that LabVIEW will override whatever has been set in MAX.

First, you can configure things in MAX and test how they work and then simply import those settings into LabVIEW. Second, code should always be protected. I build executables or password protect my VIs so that nothing can be modified. If you don't, you're simply asking for trouble. Lastly, Your comment about reloading the MAX configuration doesn't wash if some bozo with enough privileges to modify MAX does so accidentaly and doesn't know how to restore it or doesn't know where the backup is. So, in the meantime, until the responsible engineer is contacted, the entire test system is down. If the system is down during normal working hours and the engineer is local, maybe the cost of the downtime can be limited to a few thousand dollars of lost productivity. If it's during off hours (nights or weekend) and the engineer is still local, then the cost goes up. If the test system is located a couple of continents and several time zones away, the cost goes way, way up. Having to deal with this sort of issue on a daily basis, I'm glad NI made my life a little bit easier.

[probably]

Thanks for the quick response. Sorry about posting in the wrong forum, I thought I had put this in the DAQ forum but must have made a mistake.

Your point about the settings in MAX is a good one with a pertinent example, thanks for that.

But I would like to reiterate the point that a task based on a single NRSE ai global channel should not default to differential within MAX, at lest without an explicit warning that it was doing so. It took me an unnecessary amount of time to track this down, and I can see no benefit of this behaviour.

Do you have any comments on that particular point?

[Dennis_Knutson]

Don't worry about posting to the wrong forum. There seems to have been quite a few lately. I think you're probably correct that MAX should give a warning at least. Frankly, since my experience with DAQ goes back a long time before DAQmx and tasks, global channels, and all of the other new bells and whistles, the only thing I use MAX for is to check basic functionality and have never experienced your problem. I would suggest you go to the Product Suggestion Center and make your request known to NI.

[probably]

Thanks for the advice.

I get the impression that the new tasks, virtual channels, etc. are going through a bit of an introductory phase. NI's apparent philosophy of using MAX to reduce some of the work required in programming needs a bit more work yet. Your philosophy of using it just as a quick check on the basic functionality seems to be best.

That's a shame.

For anyone coming across this in the future, let me give an example: I want to measure 4 ai channels as NRSE, ai0-ai3. I set these up as global virtual channels and test them. They all work fine. Two problems:

1. I then set up a task containing these four channels to run through them all sequentially. I then test this task in MAX and it gives the wrong readings (as it's defaulted to differential without telling me). This is at odds with the philosophy of what a task is meant to be (i.e. a logical grouping of related i/o tasks which can access a set of shared global channels).

2. Referencing this task in LV doesn't even import their desired behaviour, I have to right click on the task and then generate the code, which has defeated the purpose of creating the task in the first place.

One other thing I discovered today on the PCI-6229 that I couldn't find in the documentation.

I have ai0-ai7 set up as NRSE, as they share a common GND which I have connected to aisense.  I have four other signals to collect, which also share a common ground (but possibly different from GND). My thought was that to prevent any gnd offsets, I would measure these as differential mode. So I set them up on ai8-ai11 (I assumed that ai12-ai15 would be the other terminal on each of these signals). However, you can't do this: a mixture of differential and NRSE is not allowed on the same connector. Setting the four up on ai16-ai19 allowed me to measure them in differential mode. I presume this is because of the way the multiplexer works on the input amplifier?

btw, I've found this forum tool pretty good, apart from accidentally pressing tab to get a space, then return by accident and submitting a partial post 🙂

[Tom_W_[DE]]

HI probably-

---

@probably wrote:

I have ai0-ai7 set up as NRSE, as they share a common GND which I have connected to aisense.  I have four other signals to collect, which also share a common ground (but possibly different from GND). My thought was that to prevent any gnd offsets, I would measure these as differential mode. So I set them up on ai8-ai11 (I assumed that ai12-ai15 would be the other terminal on each of these signals). However, you can't do this: a mixture of differential and NRSE is not allowed on the same connector. Setting the four up on ai16-ai19 allowed me to measure them in differential mode. I presume this is because of the way the multiplexer works on the input amplifier?

btw, I've found this forum tool pretty good, apart from accidentally pressing tab to get a space, then return by accident and submitting a partial post 🙂

---

A mixture of NRSE and differential channels is certainly allowed on the same connector.  The problem arises in the placement of channels.  In differential mode the channels are connected on two seperate channel input pins; the positive pin goes to pin ai[X] and the negative pin goes to pin ai[X+8] where X is the channel number specified for differential input.  So, on a card (or a single connector on a two connector card) you can only create differential channels on the first 8 analog input channels.  Differential input channels on ai8-ai15 are not allowed because there isn't an [X+8] pin to access. 

If you arrange your four differential channels somewhere in the first 8 inputs (i.e. ai0-ai7) and the NRSE channels anywhere else you will be able to acquire all signals in the same task on the same connector at the same time.

EDIT:  I forgot to mention one caveat that might be obvious but is still worth mentioning- using a differential channel on a pair of inputs reserves the second pin.  So, if you create a differential channel on ai6 for instance, both ai6 and ai14 will be reserved.  This means that you will not be able to use ai14 for NRSE input.

Hopefully this helps-

Message Edited by Tom W. on 08-20-2005 06:52 PM

[probably]

Thanks for that note Tom, I'll reassign the physical channels appropriately to allow me to do this. That's actually very helpful in my application!

It seems like only one possible algorithm for deducing the second input for the differential input. If I've got ai0-ai7 as NRSE, you'd think that the software would be clever enough to note that if I asked for ai8 with differential, it'd pair this with the next available free input, e,g. ai9. Or at least give me a warning on how to do this.

Or is it something more subtle than that, such as the ai0 and ai9 connectors being part of a twisted pair in the connection cable (SHC68-68EPM)?

[probably]

btw Tom, seeing as you are officially part of NI, do you have any comments to make on this issue of tasks based on NRSE defaulting to differential I was talking about earlier in the thread?

[Tom_W_[DE]]

Hi probably-

The reason the pairs are split across eight inputs is a hardware design of the board itself- there is no way to change this in software and was just a standard NI decided upon a long time ago and has worked hard to stick with.  The driver is smart, but not smart enough to overcome the hardware layout and setup.

I just attempted to replicate your global channel/task situation in MAX and did not see the same effect.  I created two global channels on ai0 and ai1 with NRSE terminal configuration and made sure to save both after making setting changes.  I then created a voltage input task and added both global channels.  They remained as NRSE and the connection diagram correctly showed connections into ai0 and ai1 and then pin 62 (AISENSE) for both channels.  I am using NI-DAQmx 7.5, so perhaps you should take this opportunity to upgrade if you haven't already.

Hopefully this helps-