[endurance_robots]

some software http://endurancerobots.com/download-center-lasers/ for creating gcode

[slimneill]

Hi Tom,

I've cleaned up the tool change and it's about 95% where I want it to be but fully functional for now. It's gotten more complicated since the last video now that the tools travel down alleys between holders so that they don't run into each other when going to the back row

My issue is that I can't get a watch dog to work to prevent or bail on a tool change if the spindle gets turned on. I have an input from the VFD IO 1046 which goes Low when ever the VFD turns on the spindle.

I've tried watch dog in different parts of the main file and it seems to hang up in the watch dog loop and not complete the tool change. Is there a better way to have the watch dog only active during the tool changing sequence and then turn off once complete?

Current Code attached...
Thanks,
Dan

[TomKerekes]

Hi Dan,

I don't fully understand your requirement. It seems you want to monitor IO 1046 and if it ever goes low during the Tool Change Sequence to abort the Tool Change Sequence? Wouldn't it be better to somehow prevent the Spindle from being turned on during the Tool Change Sequence?

But to do the former I think you would need to "sprinkle" in tests throughout the code to check for IO Bit 1046 and if low return an error code. You would only need the check in places that wait for something to happen (sections of code that execute instantly would require any checks). So mainly time delays and wait while loops. You might create a new function int DelayAndCheckAllOK(double delay) that you could call instead of Delay_sec that would include the check (and possibly others) and return an error code if the spindle turned on.

You could add a check right at the beginning to prevent anything from happening if the IO Bit is already low.

HTH
Regards

[slimneill]

Thanks Tom,

My understanding of how the Watchdog worked was wrong. I thought it worked in the background or in parallel instead of in series with the rest of the C code in the Main program.

My fix was to have the Tool Change code check that the spindle was turned off before starting. (i.e. Verify that IO 1046 is high). Then flag an Output IO high for the duration of the tool change.

I then updated my C-code for spindle CW On command to look for the status of the new flag IO and abort the any attempted SPINDLE ON command if it finds it’s state to be high. (Which only occurs during tool changes) The flag then turns off at the end of the tool change.

I’ve tested this at every step of the tool change code by trying to turn on the spindle with the on screen spindle button and it just completes whatever line of Tool change code it’s executing at the time and then stops all motion & activity. Which is safer than having the spindle turn on!

Perhaps you can help me understand how Kflop handles multiple C code routines at once? I thought it was handle multiple routines in parallel based on which thread the code is loaded in. So I would have assumed that it would continue the tool change routine regardless of pressing the Spindle on command if both C code programs are on separate Threads? (I think I’m using different threads but would have to double check that). But I’ve noticed that if I’m running a C code routine like Homing or Part Zeroing and I click certain buttons in KmotionCNC it hangs on what it was doing. Is this due to how Kmotion CNC ranks the priority of activities? It’s not a big deal, we just don’t click anything during these routines, I’d just like to understand better how it’s working.

Thanks,
Dan

[mmurray70]

Thats basically how I did mine as well. Setting an output is probably fine, but the best thing for something like this is to set a persist.userdata variable. Simply use the code: persist.UserData[xxx] = 1; and then set it back to 0 at the end of toolchange program, and have your spindle program check for it. I check for toolchanger or rigid tapping active and if either is running the M3 program will end. Code is: if (persist.UserData[161] || persist.UserData[163]) return 0; // If toolchanger or tapping active, end

These persist.userdata variables work great, they work between all programs and in different threads and i use em all over the place to set something in one program and have another program check for it. Good idea to set it equal to 0 in your init file too on start up.

[m_c]

For a simple check, setting a bit (either a virtual or spare output) is probably better than using a persist variable. Persist variables are doubles (64bit floating point number), so it's a bit overkill for a simple flag.

Regarding C programs, threads, and priorities, nothing gets priority. Every thread gets an equal amount of processing time. It's up to you to ensure they don't conflict with each other, or overwrite existing threads when loading another program. If you're getting hangs when loading new programs, you've got a conflict somewhere. It could be you're overwriting an existing running thread that hasn't completed something, or you're using variables/bits in more than one thread that's causing a conflict (I.e. you're using the same VAR setting in KMontionCNC to transfer values for more than one purpose).

[TomKerekes]

Hi Dan,

Perhaps you can help me understand how Kflop handles multiple C code routines at once? I thought it was handle multiple routines in parallel based on which thread the code is loaded in. So I would have assumed that it would continue the tool change routine regardless of pressing the Spindle on command if both C code programs are on separate Threads? (I think I’m using different threads but would have to double check that). But I’ve noticed that if I’m running a C code routine like Homing or Part Zeroing and I click certain buttons in KmotionCNC it hangs on what it was doing. Is this due to how Kmotion CNC ranks the priority of activities? It’s not a big deal, we just don’t click anything during these routines, I’d just like to understand better how it’s working.

Your thinking is correct. Programs in different Threads should operate concurrently and in parallel without any priority. They all always get their Time Slice deterministically. See:

KMotion/KFlop Multi-tasking

However if you command a Program to run in a Thread that already has something in progress running, then the previous program will be killed at wherever it was. I suspect you are using the same Thread for multiple things that you expect to function in parallel.

HTH
Regards