M6 remap in pure python lessons learned

19 Apr 2017 15:43 - 19 Apr 2017 15:53 #91639 by bevins
bevins created the topic: M6 remap in pure python lessons learned
I just finished up my M6 remap in pure python on a large multi spindle router with vaccum pods and 3 position rack toolchanger.
It was a taxing adventure but something I learned alot doing. There is very little in documentation on the subject and no code examples. I got very few responses when asking for help for some unknown reason, but thats ok because I had to dig and figure out how to do it, which was fun and daunting, but a great learning experience and I gained a ton of linuxcnc knowledge that I wouldnt have gotten if I was being force fed information.

So I will run down what I have learned in hoping someone can bypass the difficulty I had in getting the information required to get this done.

I will start from the beginning: Tx M6

The line in the ini file that starts this off in my case is:

REMAP=M6 modalgroup=6 prolog=change_prolog python=M6_Remap_BiesseRover346

Standard glue was written to help in passing values and setting up things that were awkward to do in NGC code, or RS274NGC language. With an NGC or o word type remap, you would have the change_prolog being executed which handled the Tx basically and passing on selected tool and selected pocket to the remap. The ngc code would run and do the change and give change_epilog a positive value if everything went ok, then the change_epilog would return an error and/or abort, if it wasnt a positive value, and when it was a positive value it would set some parameters, cause a interpreter sync and return gracefully and carry on with the gcode.

The problem with using stdand glue with pure python is, well .... you cannot execute three python files sequentially within a remap. I dont know why, It just doesnt call the third file. Change_epilog will never run within a pure python remap as of this version 2.8 pre. And it did not before either. this is documented in one line of the source code somewhere. I found it at one point.

So what I did was use the change_epilog1 as a function within the remap file and called it just before exiting the remap. In a pure python remap, you are responsible for setting parameters if you are using them, doing your offsets or whatever you need to do to exit gracefully and carry on with gcode.

So now we have that taken care of, the first thing that needs to be done when you enter a remap is checking which instance of the interpreter you are in. When you startup Linuxcnc and load a file, it loads the preview plot bvy running through the gcode, it is using the preview instance of the interpreter, which does not send any cannon commands or proces any move commands, or check any inputs. It runs through the gcode so it can display the plot. The problem is once it gets to a Tx M6 during loading the file, it detours hence the (remap), and in my instance runs the change_prolog and then the remap code. During the remap you are in the milltask instance which does process commands and inputs and outputs etc.... Same instance as when starting a program. So if you dont check which instance your in and exit out of the remap when loading a file, it will attempt to change a tool and probably fail miserably, with undesired behaviour and possibly breaking things. So the first thing you should do in the remap is check which instance your in like so:

Warning: Spoiler! [ Click to expand ]

This will exit the remap and finish loading the file.

At this point, you dont know if the remap is working and changing tools. If linuxcnc starts, then the process of remap is correct and working. However you do not know if your code is working, and wont know until you try running a file.

When I started out my journey of remapping, I didnt understand any of this and so when we got the remap process working I was caught by surprise in that when staring up linuxcnc it started trying to change tools and failed. No commands were executing. Now we come to the part that is the most daunting. I will briefly explain what is happening and what a queubuster is in my own words.

The interpreter knows where the machine is at throughout the gcode file. It needs to know where it is after every line because it is reading everything into its buffer and processing commands from within the buffer. If it comes to a function where there could be an outcome the interpreter cannot see re: toolchange fail, probe not working, because it cannot predict it, it cant recover because the machine will be in a different state than what the interpreter thinks it is. The interpreter will continue processing commands, but not all. It ignores commands until it can catch up to where it thinks it should be. This is called a queubuster and needs to be dealt with. What should happen is you need to tell the interpreter to stop read ahead, process everything in the buffer and then continue on.This is the grey area where I cannot find the relevant information to make this happen systematically. I have been able to keep the interpreter happy, but I would really like to know more about this. They have INTERP_EXECUTE_FINISH which is when you yield INTERP_EXECUTE_FINISH, then this is suppose to stop the read ahead, process whats in the buffer and continue on.The trick is where you do this and how many times you need to do it. this you just have to test.

In my head the best thing to do would be upon entering the remap, stop read ahead, flush the buffer, the continue through the remap until done. re sync the interpreter then be on your way. But this is not how it is setup. So you yield where you think it will cause issues with the interpreter and you should be able to get through the remap.

So the last thing in the remap is I call a modified epilog function within the remap, and set the emccanon.change_tool, and set parameters I dont use, but it makes linuxcnc happy so and finally set the toolchange_flag to True.
Then gracefully exit the remap.

A couple things I have to bring up and they are setting motion.digital-out-XX directly does not work reliably from within a pure python remap for some reason. you can check them no problem but I have had zero success setting them directly. With that being said, setting them with M62-M66 is working flawlessly. so I chose to go this route, especially because thats what the interpreter was built to do, and it doesnt it well. see below a function to drop tool.

Warning: Spoiler! [ Click to expand ]

In closing, I would like to thank the guys in the IRC channel that aided me in where to find info and tips here and there.

I am not 100 % sure everything is accurate, but in my mind it is. I am open for discussion. If anything I said is blatenly incorrect please speak up.

Last Edit: 19 Apr 2017 15:53 by bevins.
The following user(s) said Thank You: andypugh, tommylight, cts1085
19 Apr 2017 21:52 #91679 by tommylight
tommylight replied the topic: M6 remap in pure python lessons learned
Glad you got it working, bro.
I did try to do a remap on the last retrofit and waisted 2 days hunting through files, made it work properly.......except it would mess up the tool numbers occasionaly, later found out that the tool.tbl was changing when restarting Linuxcnc while i was seting up a toolchange comp from ArcEye i think, so i set up the tool table, saved and made it read only. The comp is soooo nice and so close to what i needed that it took about half hour to get it working properly, been working every day for 3 months without a single issue.
Must be nice to have that taken care of, i was following your progres all the time, but there wasnt much i could do to help.
21 Apr 2017 18:06 #91798 by BigJohnT
BigJohnT replied the topic: M6 remap in pure python lessons learned
I think your the expert now :), thanks for sharing what you learned.

25 Apr 2017 06:32 #92034 by newbynobi
newbynobi replied the topic: M6 remap in pure python lessons learned

is it possible to get the complete code?
I am on a similar problem, at actual state I am using a mix of gcode and python and sometimes I get strange behavior on the changer, like dropping the tool without opening the changer :(

Time to create page: 0.135 seconds
Powered by Kunena Forum