LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

digital waveform array into boolean

Hi, appending a zero may cause some position issues in terms of shaft position since the encoder would pulse to 1, append a 0, and pulse to 0 and repeat so the pulse waveform may be 100100100 and the counts would therfore be 3 for 6 pulses in this example - correct only if I have correctly understood your meaning - also I am unsure how I would actually append a zero to the end of the digital array. This would also mean that I would get a 360 data points (analogue loop) per rev as apposed to 720.

 

You mentioned changing the logic for triggering which I believe is possibly the way forward. I have looked at changing the logic before the case structure of the digital loop since this is what triggers the analogue loop. After looking through the boolean pallete I cannot figure out what logic would be used since I have two numbers 1 and 0 and the 0 provides the pulse aswell. It may be cheeky to ask after all the help you having given me but could you please provide me with some idea of what type of logic I should use? many thanks

0 Kudos
Message 21 of 52
(1,957 Views)

It looks like your problem is that you are using a level trigger (trigger if 5V present) and you really need an edge trigger (trigger if 0V to 5V transition).  Edge triggers are slightly more complex, because they require two points, not one.  Instead of searching to see if 5V is present, you need to search for a 0V to 5V transition.  Create a shift register in your digital acquisition loop that will cache the last point of your acquisition (initialize to FALSE).  When you get a waveform, use a FOR loop to search it for a 0V to 5V transition.  You can autoindex the array, and use the last point to reset the "last point" cache.  This code snippet should make the process a little clearer.

 

digitaledgetrigger.png

 

Note that the digital waveform is a 2D array, but it sounds like you only have a single column, so you can either reshape it (faster) or index it to get a 1D array.  Alternately, you can just autoindex the 2D array and modify the code above appropriately.

 

Don't worry about asking questions.  Most of us enjoy helping people who are trying to learn.

Message 22 of 52
(1,959 Views)

Hi DFGray, I have added your code to my program but the pulse still does not reset itself when a pulse occurs and settles on a true until another pulse occurs to settle it to a false. Following your logic I changed the OR function to an AND and still following probing the wire the trigger the same activity was occuring. In my code below was I correct to allow the response from the for loop to be wired into the case selector and the elements on the enqueue function (where the blue circle is in the picture)?

 

vi.PNG

 

I am wondering whether it may be best to implement a counter instead of a digital pulse and everytime the counter iterates it triggers the analogue. I can implement the counter system but getting it to trigger the analogue seems difficult since I can not think of which logic I could use to turn the iteration into a boolean response.

0 Kudos
Message 23 of 52
(1,946 Views)

Actually, you did not implement what I expected.  Do the following:

 

  1. Replace the Array OR with a Reshape Array to change your array from a 2D array to a 1D array.
  2. Delete the empty array cluster on the outside of your WHILE loop.
  3. Wire the 1D array output of the Reshape Array into the indexing input of the WHILE loop that the empty array cluster used to connect to.
  4. Wire a FALSE boolean constant to the top shift register of the edge detector loop (as in the original code snippet).
  5. Wire your Pulse indicator to the output of the top shift register in the edge detector loop.

Good luck.

 

0 Kudos
Message 24 of 52
(1,942 Views)

Hi DFGray, I have wired the code according to your instructions. I think it is correct:

vi.PNG

The pulse to a 1 (true) does now return to a false. The next following pulse 0 (false) also returns/remains a false - so techincally I am now missing the zero pulse so therefore 360 pulses per rev is what I should theoretically be getting. However I do not, instead I only manage to get around 60 whilst turning the shaft round slowly by hand and around 20 on a faster hand turn. I am assuming this had something to do with timing so I changed the Wait ms functions in both the digital and analogue loops to Wait until next ms multiple to help sync the loops. this actually did not seem to make much difference and pulses where still 'missing.' I initally had a 100ms for the timing and turning this down to 0ms (max cpu speed/time) - the analogue loop runs on its own without the shaft being turned.

 

Following this I increased the sample rate of the digital acqusition from 1K to 36K - which obviously allowed me to see a finer graph (more pulses) on the digital waveform graph. I also increased the rate of the analogue loop in the same manner and any rates above 10K and the program stops with the error -200279 (reading samples which are not available).

 

I only have labview running, using a Xeon CPU machine, Win XP proffessional - so cannot really understand if it is a timing issue or rate issue since adjusting both provides different results. Any ideas?

0 Kudos
Message 25 of 52
(1,923 Views)

You almost got it.  Three changes should get it working well:

 

  1. Totally remove the delay in the digital acquisition loop.  The acquisition itself delays the loop so the delay is redundant and may be causing you to miss data.
  2. Change the "1" input to the reshape array to the number of points you are acquiring (just wire the "1000" constant from outside the loop into it - you may want to cast it to an I32 first).  This is your major issue.  You are reshaping the array to size 1, effectively fetching only the first point of your acquisition.
  3. Initialize the boolean shift register with a false constant (it is currently uninitialized, leading to inconsistent results on multiple runs).

If you need to catch every transition and not just low-to-high transitions, replace the compound arithmetic node in the FOR loop with an exclusive OR and you will be good to go.

 

Message 26 of 52
(1,918 Views)

Hi DFGray - followed instructions in previous post and now the analogue loop iterates on its own without the shaft turning. I have added the delay back and still now iterates on its own behalf but obviously at a slower rate - the terminal connections were untouched and upon testing in MAX they are fine too. This is similar to my previous post where I temporarily removed the delay and a similar activity was occuring, chaning the compund arithmithic to an XOR did not change this behaviour. I placed a probe on the boolean leading to the case selector of the case structure and when the program is run is continous to remain TRUE - as a result the analogue loop runs then at its own rate. This is very strange and according to the program should not be occuring. Any ideas why it may be doing this? My updated code is below:

 

 

vi.PNG

 

 

0 Kudos
Message 27 of 52
(1,897 Views)

Changing the compound arithmetic mode to exclusive OR will guarantee the problem if you do not also remove the invert on the upper input terminal.  Or you can replace the compound arithmetic node with an exclusive OR node.  Leave the delay out.  It is just making the root problem more obvious.

 

It sounds like you have an acquisition problem. What does the data coming out of your digital waveform acquisition look like? When the shaft is not turning, is it a single value for all elements of the array?  Does the reshape array result in the data you expect?

Message 28 of 52
(1,891 Views)

Hi removed the invert so now I have a XOR function. I know you said leave the delay out but because of the speed and to identify the problem I added a 1sec delay. What I noticed is that when the digital encoder is pulses to a 1 it provides one iteration for the analogue loop and then settles to a zero (due to the logic). As it remains on a 0 (with the digital daq reading a 1 since technically the encoder hasn't pusled to a return to a 0) the following two iterations remain on a 0 so no triggering. On the next iteration the logic returns the trigger boolean to a 1 (so analogue loop iterates) and also remains at a 1 for the next following iteration after which it returns to a zero and completes the whole process again - providing the digital pulse remains on a 1. Little confusing I know

 

i.e.

iteration:               1  2  3  4  5  6  7  8  9  10 11

digital pulse          1  1  1  1  1  1  1  1  1   1  1

trigger                  1  0  0  0  1  1   0  0  0  1  1

 

This is only the case for when the digital pulse is on 1 and not when on a 0 where the trigger remains on a 0 - but this could be to due with the addition of the delay as you stated.

 

Regarding the digitial acquistion itself that responds to the encoder - provides a 1 with a pulse and returns to a 0 with the next following pulse. So when the shaft is not first turning the value is on 0. Placing a boolean indicator on the end of the reshape array it provides the same result as in the digital waveform graph; true for first pulse and false for following pulse. I have checked the acquisition in MAX by using a counter and the response is fine - could this be a logical problem in the program?

0 Kudos
Message 29 of 52
(1,885 Views)

Hi DFGray. I have been trying to figure out why the analogue loop continues to iterate after a 1 has been pulsed.

 

I placed a get queue status in the digital loop and found that as the encoder pulses the elements in the queue increase. But when the encoder lands on a 1 pulse, and remains on a 1, the elements in the queue still increase thereby allowing the analogue loop to iterate. I can only say that there is some fault in the logic of the digital loop but cannot figure out where.

 

Also if after turning the shaft encoder for some time and allowing the last pulse to be a 0 (i.e. no more addtional elements to be added to the queue) - the number of elements from the get queue status (in digital loop) decrease and the analogue loop interation increases at a slow rate until all elements in the queue have been processed. Because of this I am wondering whether the program actually responds to the encoder pulsation and processes queued up elements at its own pace. Please can you help?

0 Kudos
Message 30 of 52
(1,852 Views)