Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
download hangs
#1
I have a problem when downloading my project where it gets to the
obj/
obj/Debug/
and hangs. I can still ping the PMAC but cannot connect to gpascii and the ServoCount in the watch window stops updating. Oncly can recover by power cycling.

Eventually I figured out that the problem was one of my background apps. If I commented out most of the program (just leave main function) than I didn't have a problem with downloading.

This has come and gone for awhile now. When I just build there is no problem and con compilation errors. Sometimes it matters if I am running the program at startup. In pp_startup I enable plc 1 which runs the program (system "/var/ftp/usrflash/Project/C\ Language/Background\ Programs/perimeter_interlock.out").

Any suggestions?

Another question:
Any was to redirect program output to the IDE or screen? Like printf or MessageBox? Or can I declare a string variable that's visible in the IDE?

Thanks
Reply
#2
Looks like the problem was using too much CPU. I added a sleep statement and it seems fine now.

So now 2 questions remain:
1. If I want run my background app at something roughly approximating a PLC routine, should I be adding a sleep of 10ms or 1ms or another way or lowering the priority?
2. Any was to redirect program output to the IDE or screen? Like printf or MessageBox? Or can I declare a string variable that's visible in the IDE?

Thanks
Reply
#3
1. would use a bgcplc (background c plc) instead of a background app. They already run a set number of times per background cycle.
2. The easiest method would be unsolicited messages. The feature was really meant for sending strings to an HMI, but the IDE is easily capable of receiving and displaying the messages. Take a look at the send command in the software reference manual for more information about building formatted strings to display. Also see attachments.


Attached Files Image(s)
       
Reply
#4
(07-27-2020, 10:06 AM)Eric Hotchkiss Wrote: 1. would use a bgcplc (background c plc) instead of a background app. They already run a set number of times per background cycle.
2. The easiest method would be unsolicited messages. The feature was really meant for sending strings to an HMI, but the IDE is easily capable of receiving and displaying the messages. Take a look at the send command in the software reference manual for more information about building formatted strings to display. Also see attachments.

1. After some experimentation, I need a sleep of not longer than 2.5ms in order to catch the position changes at a high enough frequency. Will that be compatible will the background plc?
2. Initially I had some trouble but later on it worked very well. Maybe the socket wasn't open in the beginning? Anyways works well and should make debugging a lot easier.
Thanks
Reply
#5
1. This really comes down to exactly how loaded your CPU is. The background takes as long as it needs to to complete a cycle (which includes multiple runs of each bgcplc) and then waits for a specified amount of time (default 1 ms) before repeating.

If your code is not too math heavy (I mean things like trig that actually cause some CPU load) you should be able to make it an rticplc. This way it would run at the real time interrupt frequency.

2. Glad to hear it.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)