LabVIEW
FPGA parallel while loop + Loop Time Problem
Solved!
@ODONG5 wrote:
Here are my codes
Ok, thanks. Here are some comments and questions:
- (On RT) You can just output a True Constant from the first For loop rather than doing the = comparison each iteration, and set the tunnel mode to "Last Value" to get a true at the end (i.e., "is done")
- You have a wait in the second frame (first While loop). Why is this? This occurs before you start writing any pulses, so it won't control the time between positions
- As in frame 1, with the Start LED in frame two (inside the While loop) you could move this outside of the While loop and use a Last Value true constant to populate it.
- In the 3rd frame you do the same again with a "done" type of boolean output. Since this will always be true, the case structure in the 4th frame will never be false. You could remove it.
- Period (us) is the only thing that changes with the position being targeted. Is this the expected operation?
- In the second frame (where you calculate e.g. direction) you could remove the loop by operating on arrays. An example is shown below.
- (On FPGA) What are DIO14 and DIO15 connected to? I'm guessing these are part of the encoder circuit, but is one governing direction? You have both checked for changing edges (either direction) but your CW/CCW choice is made by DIO14 XOR DIO15(prev), which I can't quite guess the meaning of.
- One of your buttons (top right) outputs to the Z1 En_Pulse terminal, but I can't read it (sorry). It doesn't appear to be controlled by the FPGA node on RT. Is this intentional? I guess it is always false in this case.
- The "Loop_EN_Timer(Inner)" value will slow down the FPGA encoder loop, but not the RT loop that samples it. As a result, you'll sample data every 500us regardless of the value of this control. Is that intended? You might be better off just removing this delay in the FPGA code if it isn't playing some other important role. It may cause you to miss edges, if it is too long (e.g. if you go on DIO14 or 15 from T->F->T without measuring the F).
Given your discussion of a delay previously, I'd say that number 2 is the most likely to be important point. If you remove that wait, you might speed up some timing issues. However, it won't change the intervals between movements (which is controlled by the 500us wait).
Thank you for your comments.
First, I revised my code in 1-4 comments.
In comment 5, you are correct. I want to change only period of pulse, then the change of period also changes the number of pulse in interval time. The number of pulses in interval time finally decides the velocity of the motor.
In comment 6, I understood what you mean. but is it also okay with no change? right? No?
In comment 7, DIO14 and 15 are connected encoder sensor pulse. It is a quadrature encoder. So there are two pulses A, B.
The phase difference between A and B is pi/2. The motor direction change makes which pulse go first. And I can check this change by using XOR between current A and previous B.
I upload the figure to help you understand easily.
In comment 8, I add the TF control button for that output. This output has a role to set the Z1_encoder_value '0'.
In comment 9, I was worried that 500us is not proportional to while loop( DIO 14/15) time and it makes some problems. Is it wrong thing? If I delete this delay, can loop-time be proportional to 500us(outer while loop, RT) ?
I changed my code and implemented that. But, there is still the gap between reference and sensing value ( about 100ms...) .
I don't know why it is.. 😞 It is so difficult.
@ODONG5 wrote:
In comment 6, I understood what you mean. but is it also okay with no change? right? No?
Oops - I said I'd show an example and then forgot. But yes, it's not necessary to operate on arrays - element by element as you currently have it will work.
@ODONG5 wrote:In comment 7, DIO14 and 15 are connected encoder sensor pulse. It is a quadrature encoder. So there are two pulses A, B.
The phase difference between A and B is pi/2. The motor direction change makes which pulse go first. And I can check this change by using XOR between current A and previous B.
I initially thought there was a problem here, because the output is not always the same as the direction, but then I saw that since you only need it to be true when either A or B is changing (because of the select node) it works correctly.
@ODONG5 wrote:In comment 9, I was worried that 500us is not proportional to while loop( DIO 14/15) time and it makes some problems. Is it wrong thing? If I delete this delay, can loop-time be proportional to 500us(outer while loop, RT) ?
Regarding comment 9, you don't necessarily want the two loops to run at the same rate. It's OK for your FPGA to sample very quickly, since it will only increment when there is a changing edge. Therefore it should try and run as fast as possible to avoid missing edges. You only need the Z1 EN_Pulse indicator to be updated when you read it on the RT system, so update it often and it will always(nearly, and always compared to the RT system) be up to date.
However, on the RT system, you do need to wait, since that controls the rate of change of the "Pulse" input to the 3rd frame While loop.
I would try removing the Wait on the FPGA (in the top loop - the bottom loop waits of course control the output pulse) and see if it changes your result. (Also remove the Wait until next in the 2nd frame on RT - maybe you already did this).
