Question about the value of state.currentTool

Leonard03

Hello! This is my first answer to aomone on the formum, so I apologize if I make any mistake

I have a setup with am MMU2. What I've seen is that the any value in OM is updated after any tool change macro is completed. So, again, if I not mistaken, the T-1 command will update state.CurrentTool after the tfree has completed

fcwilt

@Leonard03 said in Question about the value of state.currentTool:

Hello! This is my first answer to aomone on the formum, so I apologize if I make any mistake

I have a setup with am MMU2. What I've seen is that the any value in OM is updated after any tool change macro is completed. So, again, if I not mistaken, the T-1 command will update state.CurrentTool after the tfree has completed

That appears to be the case.

But as you can see when mounting a tool there is an event (TPRE) before the value changes, and another event (TPOST) after the value changes.

Ideally, for my needs, when dismounting a tool there would be a similar pair of events "TFREE_PRE" and "TFREE_POST".

There are other ways I can get it to work but the mythical event "TFREE_POST" would be the simplest.

I will continue to ponder the alternatives.

Thanks much.

Frederick

Leonard03

I can think to an idea about running some code if the current tool is -1 but it will work only if you change tools, something in tpre, not with the current tool but with state.previousTool:

In the tpre file you can start with the statement:
If state.previousTool = -1
else....

But if you unload your tool, i guess that your only option will be via deamon.g and some kind of global variable to indicate if the code from deamon should be executed or not.

This is my ideea, but I dont know if it will or not but anyway:
In daemon.g you can see if a new tool is pending the load and the current tool that is used.

I would combine two statements something like
If state.currentTool = -1 && state.nextTool = -1
Code to execute

fcwilt

@Leonard03

Yes, using the deamon is one approach that could work - I would just have to ponder if the potential delay in the deamon executing my code would be a problem.

I may decide that what I want to do is not really something I need to do.

Dealing with changing tools is a new area for me and am still learning.

Thanks for the feedback.

Frederick

gloomyandy

@fcwilt So what is it that you need to do when the tool is set to -1 (other than free the currently selected tool)? I've not found any need to do anything in that situation with my toolchanger.

dc42

@fcwilt if you want to know whether another tool is about to be selected, or just the current tool released, you can test state.nextTool.

fcwilt

@dc42 said in Question about the value of state.currentTool:

@fcwilt if you want to know whether another tool is about to be selected, or just the current tool released, you can test state.nextTool.

That is just what I need.

Thanks much.

Frederick

fcwilt

@gloomyandy said in Question about the value of state.currentTool:

@fcwilt So what is it that you need to do when the tool is set to -1 (other than free the currently selected tool)? I've not found any need to do anything in that situation with my toolchanger.

Well let's backtrack a bit and let me ask a basic question.

On a typical one tool machine I home the Z axis first and when homed it is "parked" it at Z=10. Then I home X and Y and they are "parked" at X=0 Y=0, which is the center of the bed on all my machines.

Now on a multi-tool machine when a tool is mounted:

is homing allowed?
if so, after homing all three when I "park" them at X=0 Y=0 Z=10 would I use machine co-ordinates or would I take the tool offsets account?
or is my thinking totally mess up?

Thanks much.

Frederick

gloomyandy

@fcwilt It might help if you provide a bit more information about your printer. The following probably does not answer all of your questions but it may provide something to think about.

On a e3d toolchanger (which is what I have), you would normally home x and y first and then use the probe/switch on the toolhead to home z. Once a tool is selected that probe is no longer available so you are not able to home with a tool attached. I'd strongly recommend that you make the position after homing such that a selected tool will not hit the bed (if you don't at some point you will screw up and crash into it). On my setup I have code in the tpost macro that will return the new tool back to the previous (before the tool change) position (including the Z height). I think you were asking about this in another thread. The way to do this changed recently. See point 4 in the 3.4 release notes: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-340

My toolchange macros are based on those used by e3d (and I think DC42), though I have added some extra code to prevent homing if a tool is attached (I added an extra switch to the standard toolhead to detect an attached tool).

fcwilt

@gloomyandy

I am working with the E3D MS/TC setup.

The link was very helpful because it answered my other question in that other post. I should read the release notes more often, which won't be hard because to date it has been never.

I like the idea of the extra switch. It would solve another question I have been thinking about.

Thanks VERY much.

Frederick