07-02-2012 12:07 PM
Hello! I have two cycles. the first cycle of "fast" (50 Hz), the second cycle of "slow". I want to use the rapid cycle of data from the GPS receiver. But in this version I get a delay in the fast cycle (see 1). Why is this and how to get rid of? PS if you put "milliseconds to White," more than 300 ms, the data from the GPS receiver will be made smaller.
07-04-2012 09:15 AM
First of all, without the full application you have made, nobody can predict how the code will run..
As far as I can see, the "slow" loop is waiting the most of the time on the GPS data. The GPS data will be generated by the GPS receiver once a time per second. Since your "slow" loop is waiting for 300 bytes, the "fast" loop will run at full speed.
once the GPS data is available (and 300 bytes are available in the serial port), the "slow" loop will process the GPS data.
I think in that case the "fast" loop doesn't run and after the GPS data is processed, the "fast" loop will get it's execution time again.
that why you see the high delay each (second) time I think.
try using timed loops and disable parallel execution in the build specificationin your project.
Good luck with your project.
07-06-2012 01:07 PM
Would you please post the picture in the same thread?
I am confused about your statement along with your post about the error. You say that “Debug on TCP. USB jtag work correctly.” You will need to use the USB JTAG to connect and push code to your board.
The error you are getting is just a generic error. Are you able to deploy any piece of code or is there only one particular VI that causes this error?
Let us know.
07-10-2012 02:03 AM
I think that he means that he has changed the debugging mode in the build specification from USB ULINK2 JTAG to TCP port.
I never use debugging in LabVIEW because I think it's not very usefull, but I think there's something wrong with the TCP port.
But why do you want to use TCP port debugging instead of the normal JTAG?
07-11-2012 03:05 PM
Try forcing the project to rebuild (select "Rebuild All"). JTAG debugging inserts some startup synchronization code that may still be present, thus hanging (ie. target is expecting JTAG while host is doing TCP).