generating pulse with KRC4

Low frequency could be generated by Timer programmed in Submit.

"Frequency or amplitude"? Are you trying to create a pulse, or a pulse train? Also, since $OUTs are simply Boolean variables, there is no "amplitude" to control -- they're either True or False.

A PULSE command can control the state of a $OUT for a set number of milliseconds (down to the resolution of the KRC, usually 12ms). The pulse duration can be a hard-coded value, or a variable.

To create a pulse train, with controllable frequency and amplitude, you would first have to establish how many $OUTs you are going to dedicate to controlling the amplitude, which will define your resolution. Then you would have to (probably) create a subroutine in the SPS that would cyclically control those $OUTs every 12ms to generate the waveform you desire.

My answer is: you will never get precise and repeatable timing on digital outputs.

SPS is not running at a fixed rate! While you can use a timer to set/reset a $OUT, the SPS cycle frequency will vary with the logic run inside it (if-else blocks can affect the SPS cycle frequency), so it will add jitter to your signal.

The only way I've been able to achieve precise timing is by using triggers, so during motion (I've been working on a robotized dotmatrix printer project).

diglo

It's entirely possibly to get constant timing with the SPS, but it requires careful programming, probably using state machine styles. And yes, the IF/THEN branches can cause issues, if the branching code becomes long enough to exceed the total time slice of the SPS. This is where very careful code structuring can be required.

Basically, everything in the KRC runs on a 12ms cycle. In each 12ms cycle, every task (motion planner, I/O refresh, Level 1 interpreter (motion program), Level 0 interpreter (SPS), etc) gets a certain fraction of that 12ms to execute. The SPS gets, IIRC, about 2ms. If your SPS program is long enough that it takes more than 2ms to execute, the SPS will execute as much as it can during that 2ms window, then get "paused" while the other tasks each take their turn. Then, when the SPS's next turn comes around, execution will resume from the line where it was paused.

On older controllers, this used to be a bigger problem, but on KRC4s, I've done some very complex SPS state machines and never yet seen an issue with the code execution time exceeding the SPS time window. This is because, as processors have gotten faster, the 12ms time cycle on the KRCs has not changed (ignoring some special cases, and some upcoming controller rumors), but the line-execution time has gotten faster -- basically, the SPS still gets the same 2ms out of every 12ms that it had 20+ years ago, but the number of lines it can execute in that 2ms has gone up quite a bit. IIRC, the single-line execution time is somewhere down around 50 nanoseconds, these days.

Still, programming an SPS with a reliable cycle requires careful programming and thorough testing. Waits must be avoided entirely, and branches and sub-loops must be managed very carefully. For small SPSs, it's probably not too hard to just rely on the fast processor speed and brute-force the execution. But you'll need to ensure that you've tested your SPS code across all its branch conditions while checking the timing.

There's an option package called KUKA.MultiSubmitInterpreter, which allows you to run up to 8 different SPSs simultaneously (we have it on our testing robot at the workshop)

You may use one instance only to generate your signal.

diglo

One cautionary note about MultiSubmit: there are certain other Tech Packages it cannot co-exist with. DirLoader is the one that I ran into personally. So before getting it, make sure to check with KUKA that it won't conflict with whatever other options you're using.