JeffB Posted July 25, 2020 Share Posted July 25, 2020 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 Link to comment Share on other sites More sharing options...
JeffB Posted July 26, 2020 Author Share Posted July 26, 2020 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 Link to comment Share on other sites More sharing options...
Omron Forums Support Posted July 27, 2020 Share Posted July 27, 2020 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. Link to comment Share on other sites More sharing options...
JeffB Posted July 28, 2020 Author Share Posted July 28, 2020 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 Link to comment Share on other sites More sharing options...
Omron Forums Support Posted July 28, 2020 Share Posted July 28, 2020 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. Link to comment Share on other sites More sharing options...
Recommended Posts