|
Hey All,
?
I have 3 programs on my processor, how can I control when one is started vs the other?
For example: On system reboot, I don't want program 2 to start until I tell it to.
?
Thanks
|
Look in the device extenders for the processor. ?System Monitor>System Control
Hey All,
?
I have 3 programs on my processor, how can I control when one is started vs the other?
For example: On system reboot, I don't want program 2 to start until I tell it to.
?
Thanks
?
|
Thank you, I did see that. But on reboot, how can you tell program 2 not to start?
|
If the mentioned extender doesn't do what you need, you might have to play around with (un)registering the program [slot] via console commands. Hopefully clever use of the native option does the trick, as I fear my suggestion may not be bullet-proof and/or sloppy. I *think* that, on reboot, all registered programs auto-start, hence the suggestion to try the progreg commands.
|
System Monitor>System Control will only help if you want to control the timing, not for preventing the program from starting entirely. If that signal is never set high to start the next program, it'll auto-start after 30 minutes. Side note: while a slot is being prevented from starting using this signal, you'll see "......." in the console, to show the progress/waiting.
?
I've done this with a program running in slot 10 that just monitors the others (using the native object that shows when a program is running). Or you could do it from your slot 1 program. If a program starts that shouldn't (as in, when the program is first loaded), the slot 10 program opens a console SSH connection and stops that program. It also unregisters it so that a reboot or power cycling won't start that program. Then when I want it to run, my slot 10 program registers the slot and starts that program, all via the console connection. This programmatic control seems to stop the newly transferred program within a few seconds, which was sufficient for my application.
?
Another option would be to load the program using an FTP transfer. There's a console command to unpack and start the program, but there's a variation on that command to unpack it but don't actually start it. So you could do that and then unregister it to prevent it from starting until you register and progreset it.
?
I have a bunch of notes on how to do this if you want them. It's a little complicated to set up, but it's working reliably.
?
--
Josh Winn
The LiquidPixel Group
|
@Josh, sure send them over.
|
- STOPPROG -p:1
- Stops the program in slot 1 (leaves it registered, even though it says something about unregistering)
- PROGRESET -p:1
- Restarts or starts the program in slot 1, if one is loaded and registered
- Same as triggering the SIMPL > CP4N > SYS MONITOR > SYS CONTROL input labeled "start" (it will restart a running program)
- Same as DEBUGGER > SIMPL DEBUGGER > RESET PROGRAM
- Same as the RESTART button in the Toolbox program transfer dialog
- Useful for observing runtime initialization in Debugger, since it doesn't kill a Debugger session like loading new code does
- PROGREG
- If you unregister a slot, it will no longer start up after a reboot
- This is useful if you want to control when a program starts, and only have it start when you manually register & start it
- Loading a new program will always register it and start it, so you have to manually stop and unregister it after loading
- Unregistering a program while it's running will do nothing immediately (the program keeps running); a RESET will fail
- Registering a program does nothing immediately, but it can now be started (PROGRESET)
- These two commands aren't acknowledged in the console, but they do work (SIMPL > SYS MONITOR gives feedback immediately)
- PROGREG -p:1 (registers the program in slot 1)
- PROGREG -p:1 -u (unregisters the program in slot 1)
- PROGREG (gets currently registered programs; reports program ID tag if program has been started since registering)
--
Josh Winn
The LiquidPixel Group
|
Also, the SSH Interface v1.8 in the database lets you connect to the console from within your program. But make sure you give it the right credentials, and never accidentally load it to another processor with different credentials or it'll lock the whole thing up. It has an auto-reconnect time of 0.05s, which will bring down a CP4. I'll load my fixed version (v1.8.1) to the files here. It has a 30s retry and gives you a notice in the console instead of just silently killing your processor. And don't try to keep the console connection open permanently. It'll break eventually, with no indication that it isn't working anymore. Instead, open it when you need it, then close it.
--
Josh Winn
The LiquidPixel Group
|
Thanks for sharing, Josh!
toggle quoted message
Show quoted text
--- On Monday, March 10, 2025 at 9:17 PM, josh@LiquidPixel wrote:
Also, the SSH Interface v1.8 in the database lets you connect to the console
from within your program. But make sure you give it the right credentials, and
never accidentally load it to another processor with different credentials or
it'll lock the whole thing up. It has an auto-reconnect time of 0.05s, which
will bring down a CP4. I'll load my fixed version (v1.8.1) to the files here.
It has a 30s retry and gives you a notice in the console instead of just
silently killing your processor. And don't try to keep the console connection
open permanently. It'll break eventually, with no indication that it isn't
working anymore. Instead, open it when you need it, then close it.
|
I get that you are doing it with console commands, but system control has signals for start, stop, register and unregister for each program slot, as well as feedback for each. ?I have only used it to stop and then [re]start a running program slot (after the stupid Sony ZA Series AVR module barfs), not to unregister or register a slot. ?If you assert the signal to unregister a program slot does it not actually work? ?It just seems simpler to just use the built in symbol, unless it doesn't work . . .
toggle quoted message
Show quoted text
On Mar 10, 2025, at 9:59 AM, josh@LiquidPixel < jwinn@...> wrote:
System Monitor>System Control will only help if you want to control the timing, not for preventing the program from starting entirely. If that signal is never set high to start the next program, it'll auto-start after 30 minutes. Side note: while a slot is being prevented from starting using this signal, you'll see "......." in the console, to show the progress/waiting.
?
I've done this with a program running in slot 10 that just monitors the others (using the native object that shows when a program is running). Or you could do it from your slot 1 program. If a program starts that shouldn't (as in, when the program is first loaded), the slot 10 program opens a console SSH connection and stops that program. It also unregisters it so that a reboot or power cycling won't start that program. Then when I want it to run, my slot 10 program registers the slot and starts that program, all via the console connection. This programmatic control seems to stop the newly transferred program within a few seconds, which was sufficient for my application.
?
Another option would be to load the program using an FTP transfer. There's a console command to unpack and start the program, but there's a variation on that command to unpack it but don't actually start it. So you could do that and then unregister it to prevent it from starting until you register and progreset it.
?
I have a bunch of notes on how to do this if you want them. It's a little complicated to set up, but it's working reliably.
?
--
Josh Winn
The LiquidPixel Group
|
MSTC makes a good point, about using the built-in symbols. As far as I know, they do work. In my application, I was managing several backup CP4s in a redundant system. Each one was the backup for several room CP4s. UDP heartbeats communicated processor status and then when a failover was needed, the backup CP4 would register certain slots (depending on which room CP4 had failed), change its hostname, and reboot. Since the slot numbers varied depending on which CP4 had failed, and I needed to change the hostname too, I was handling all that in a module that generated console commands, rather than by triggering the digital inputs on the SIMPL definitions. But for other applications, the digitals might be the better approach since you don't have to manage a console connection at all!
--
Josh Winn
The LiquidPixel Group
|
I've used this type of functionality on basically every system I've programmed in the last 10+ years. The best way to manage this is to use the "System Monitor" > "User Program Init" >"ProgramInitComplete" command in SIMPL windows. This works without issue and allows you to specify when you want the NEXT program to start. The benefit of this is that you don't have to rely on some hard coded timing to start the next program, you can wait until whatever variable is satisfied and then start the next program. This works in each program slot and has been the most reliable method for me. The only limitation, which I've never really encountered is a 30 minute timeout where the next program will start after 30 minutes if your ProgramInitComplete signal is not driven high.
|
@Alex can you explain how you do it exactly? That signal always confused me.
|
?
Your "PROGRAM_IS_READY" signal can be driven by whatever logic you want.
?
|
@Alex, LOL love the simple explanation. My confusion is here, what if I don't want program2 to start until next week? Stupid example but hopefully you get what I am trying to do here. My understanding is this just staggers the startup of other programs. Like others have said I need to stop program2 immediately on system reboot and restart it as needed.
|
My understanding of the operation of the "SystemControl" symbol makes me think this is what you would do.
You have logic built in program 1 that is going to direct the other program slots to run their programs or not. ?You cause program 2 to not start immediately by defining and using "ProgramInitComplete". ?While you delay the start of program 2, you unregister program 2 and any other program you do not want to start up. ?When you want program 2 to start, you first register the program then you start it.
The first time program 1 runs and unregisters program 2 will cause program 2 not to run even if the processor reboots, until you register program 2. ?If the processor is rebooted and unregisters a program that was already unregistered, it will not cause any undesirable activity.
toggle quoted message
Show quoted text
@Alex, LOL love the simple explanation. My confusion is here, what if I don't want program2 to start until next week? Stupid example but hopefully you get what I am trying to do here. My understanding is this just staggers the startup of other programs. Like others have said I need to stop program2 immediately on system reboot and restart it as needed.
|
I agree with MSTC's method. If 30 minutes wasn't enough time to start program two then you'd need to unregister any program slot you don't want running and then register and start the program slot using System Control whenever you're ready.
|
This is an interesting thread!
Just so I'm clear with what others have noted, you're suggesting using a console symbol in Slot 1 (The 'Master control' Program) to send things like StopProg -p:x and ProgReset -p:x, Correct? or have you found that the ProgramControl Slot 'digital' program command start/stop work well?
?
I, like Alex, use the "ProgramInitComplete" with each slot program (learned from him!) to gracefully manage the start of each subsequent Slot.
?
|
I just did some testing, and here's what I found:
?
(TLDR: Don't use ProgramInitComplete for anything other than tweaking the timing of how the programs start up.)
?
When ProgramInitComplete is defined and kept low, you'll get a dot in the console every second to let you know there's a program start pending. During this time, you cannot load to any subsequent program slot. The load will fail, saying "The device reported an error:?System is loading another program. Failing program load."
?
You can get around this by loading the other slots first, then after a reboot, only slot1 will startup, and you'll have 30 minutes to UnRegister any other slots you want to prevent from starting. After 30 minutes, the console will say "Program(s) Started..." but since no additional programs are registered, none will actually start. This is a messy solution, and doesn't auto-stop programs when you load them. It only helps to prevent startup after a reboot.
?
The cleanest and quickest way to prevent programs from running when loaded or after a reboot, is to use the device symbols under CP4>System Monitor>System Control. I just tested this with a stepper triggered by Program2_Start_F. The outputs of the stepper were directly tied to pulse Program2_UnRegister and then Program2_Stop. All four time values of the stepper were set to 0s (single logic solution pulses with no delay between them). This solution worked perfectly when loading program 2 and also works after a reboot.
?
Of course, this would never allow program 2 to run, so you'd need some additional logic to determine when to allow it and when to prevent it. Also, keep in mind that a program that's unregistered and stopped will be basically invisible, and the next time you try to load to a slot, it'll suggest the first empty slot, and you'll need to keep track of where you have programs sitting unregistered for later use. You can see all loaded programs using the File Manager though. I think that's the only way to check for the ones that are unregistered/stopped.
?
Unregistering and stopping a program this way takes less than a second, so although the program does run briefly, you can write it to ensure that it doesn't do anything in the first second, so it effectively didn't run at all. In real world applications, it may run just long enough to have a few devices connect to their IPID in the program. I'm not aware of any good way to prevent that, but I doubt it's worth worrying about.
?
The method I suggested earlier, using an SSH Console connection and sending commands to unregister/stop programs does work, but it's more complicated and reacts slower when a program is loaded, since it has to first open a console connection before sending anything. Either works, and I was doing a bunch of other stuff with the SSH Console in that project. Using the System Monitor>System Control is easier and more responsive though, so that's my recommendation.
?
--
Josh Winn
The LiquidPixel Group
|
josh@LiquidPixel