Counter timing issues

[CodyNO]

Hello!

I am using an NI USB-6001 to calculate the speed of a moving wire. 

The wire rotates a wheel with a known diameter and an inductive sensor pulses 4 times each rotation when it detects holes evenly spaced around the wheel. 

The sensor output is connected to the P2.0/PFI 0 input. 

I use a counter function The Daqmx U32 single channel single sample. Each time the aquisition loop runs I use a get time in seconds function to timestamp the aquisition.

I calculate the speed in a paralelle loop by subtracting the timestamps taken from the 2 newest counter increments. 

The program also does other tasks such as monitoring other inputs and uppdating outputs. It also collects values in an array and writes an excel report when data gathering has ended. 

When the wire was pulled by a machine at a relatively constant speed I noticed spikes in the graph for the wire speed. 

I suspected there was a hardware fault so I made a pulse generator from a PLC and connected it to the counter input and got the same results. 

Now I suspect there is a timing issue or it has something to do with OS scheduling and labview priority. This is running on a windows 8 laptop.

Any ideas?

[mattsnow]

Hello CodyNO, 

Has there been any change in the problem in the last couple of days? 

When you connected the PLC pulse generator was the result exactly the same or did the behaviour vary? 

If it did have something to do with OS scheduling or labVIEW priority then a quick thing to check would be trying it on another machine. Have you got one you could easily do this on?

Would it be possible for you to analyse what is happening at these spikes in more detail? By the looks of it it's either the distance or the time that is erroneous in the speed calculation, I suppose it's much more likely the New / Last distance is an incorrect value and it would be interesting to know exactly what these values are when compared to typical results.

[CodyNO]

Hello Matt and thanks for the reply.

I tryed a few things and then put the problem on hold due to other more pressing responsibilities.

I did try to use a normal digital input instead of a counter that way I could recieve a single sample waveform that includes a timestamp directly from the DAQ. 

I then just programmed a crude edge detect to count. 

This did not solve anything, the spikes were identical. 

The DAQ however does not contain a clock so it seems like the problem is due to the timing of execution of the aquisition loop.

This does not explain how even in size the spikes are however. 

I did look through all the code to find a wait block or any other form of delay but there was none. 

When I increase the speed of the pulses over 10 per second I do get much more spikes. It also seems to be more likely if I have many other aplications running on the PC.

The problem is identical when I simulate the hardware with a plc.

I have tried on 2 different pcs. My laptop is not uber powerful but has been more than enough for labview, PLC and scada programming. On it I have been running this program in labview 2014. 

The other computer is the clients laptop that is attached to the machine it should run. it has windows 8 and the programi is running in a runtime engine. That is a relatively cheap machine. 

I could try to install a runtime engine on the most powerful computer we have on site. But since the application must run on a much less powerful machine I dont see the point. 

The speed measurement on this device does not have to have such a high resulution. That is the reason we bought the cheapest DAQ available.

I have deceded to change the philosophy and calculating the speed only once every second. That would give me the average speed for the last second but that is good enough for this application. 

I will make sure to use a more suitable hardware the next time I need accurate timing.

Kind regards

Tryggvi Thorhallsson

//Cody is the name of the company I work for //

[mattsnow]

Hello Tryggvi,

Thanks for your reply. It does sound like the problem is something to do with timing in the program. As you say there is no clock built into the DAQ device so it looks like a problem with the computer. The fact that the problem becomes worse when more applications are running backs up this hypothesis. 

It would be interesting to see if the problem still occurs when ran on a more powerful machine, but if the production machine is quite low power then this is probably not worth your time (unless you are very interested with this problem!). The only other thing I can think of is trying the program on the LabVIEW 2015 Development / Runtime, or even an older runtime to see if there is any change in the behaviour. 

I am glad to hear that you are able to work around this issue to obtain suitable results in this situation, but I hope in future you have more success in taking high frequency measurements. 

Kind regards, 

Matthew