Background programs

I've yet to find an example, but fortunately it seems to work in a pretty straightforward fashion, just working from the KAREL reference manual. This should give me a workaround if I can't resolve the root reboot issue.

Now off to my next problem... when my TP background program is running, UO[3] is on, even when there's no robot "foreground" task active. My KAREL programs don't do this, but I suspect it's b/c I'm using %NOBUSYLAMP in the KAREL programs.

I'm guessing that the header setting BUSY_LAMP_OFF in the TP program would have a similar effect? Still searching my Fanuc manuals for any entries that explain what values do what in that setting, though.

ADDENDUM: Got lucky: tried changing BUSY_LAMP_OFF from 0 to 1, and now when the TP background program is running, UO[3] is still off. This looks like what I need.

Still looking at my alternatives to get around this. One idea we've kicked around is creating a BG program that, on boot, would set a DO, that would be cross-mapped to a DI, that would fire a Macro that would fire my BootLoader program. I don't have any BG or Macro experience, though, so I'm trying to figure out if this would actually work.

I've also found the "Hot Start Complete" output in the System Config -- is there a signal like this that works for any reboot type? I'm wondering if I could tie that signal to the Macro and bypass the need for a BG program.

Addendum: a teamate tried setting up my BootLoader as a Macro, and creating a BGL program that would trigger the signal linked to that macro whenever the background programs were not running, and it appears to work for any of the reboot scenarios. The only downside is that whenever we kill the background programs, the BG&Macro restart them immediately, so we have to manually stop the BG program before we can make any edits.

Quote from chibai

Did you solve your problem? I think we met the same situation.

I want to running a Karel Server Poragm background, while run a TP program manually step by step

IIRC, we did what Nation suggested. We also played with monitoring system variables -- for example, using the robot being in Teach mode to block the auto-restart.