I am currently having problems with reading three hall effect sensors in simultaniously with Labveiw. I am currently using a cDAQ chassis with a NI 9401 DIO card. I am getting the error about resources being reserved. I looked into error 201133 and I am unsure if it will solve my problem. In MAX I setup all of my tasks with different channels being used. I then set up the sequence suggested in the error 201133 help page and tried with all of the "DAQmx start tasks" in the first sequence block (shouldn't really do anything different but heck) and with the "DAQmx start tasks" in three seperate frames but neither worked. I was wondering if anyone else has tried to hook up more than one hall effect or if someone would be able to explain better the error I am getting and how I can possibly solve it.
Can you say a bit more about your Hall Effect Sensors? Am I correct that they are "digital" devices that output either 0V or 5V, with essentially nothing in between? I notice that the NI 9401 is a DIO module that allows reading a 4-bit Port, meaning you can read 4 digital bits simultaneously (and you only need to read 3, so you should be Good to Go). Just be sure to wire to DI0..3 or DI4..7.
It sounds like you are trying to start multiple tasks at the same time using the same device. By doing this, the first task is locking the device and the second and third task will not be able to access the device until the first is complete. Why not put all of the channels in one task?
I am currently using the hall effect sensors to record the speed of three different shafts and, yes, the sensors I have behave the way you described where they send out a 0V or 5V signal. I was wondering if you knew if a good way to get frequency just reading them in as a digital input instead of a counter.
I tried what you suggested in MAX but I get an error saying that in order to have multiple counters need to specify them in different tasks. I don't think I mentioned this in my first post, but ultimately all I am looking for is a frequency that I can then correlate back to shaft speed.
OK, so you have a sensor on a shaft and it emits a TTL signal. Your question is can you estimate the speed of the shaft from this signal, right?
Let's assume that you are sampling much faster than the shaft speed, for example, 1KHz for a 100 rpm shaft (so you'd get 600 samples/revolution). Let's also assume you get one pulse of some width every revolution (the pulses might not be the same width each time, but should be within 1 of each other). Let's also assume that you are interested in estimating shaft speed much slower than the shaft spins, i.e. you can take, say, a minute of data and report the average shaft speed over that time interval.
Well, it's conceptually simple -- count the number of 0-to-1 transitions over a minute, convert to RPM (or whatever unit you want). But counting transitions is both boring and possibly error-prone.
Consider the following (partial) algorithm: