qtDragon toolchange and toollength setting

More
4 years 11 months ago #227136 by cmorley
Yo have a mistake in the posted Oword file - it still references gmoccapy.blockheight
The following user(s) said Thank You: ikkuh

Please Log in or Create an account to join the conversation.

More
4 years 11 months ago #227178 by ikkuh

Yo have a mistake in the posted Oword file - it still references gmoccapy.blockheight
 
oops, thanks

Please Log in or Create an account to join the conversation.

More
4 years 11 months ago #227263 by cmorley
Would having the enable button on the toolchange dialog work better.
I probably could add that option.

Please Log in or Create an account to join the conversation.

More
4 years 11 months ago #227280 by ikkuh

Would having the enable button on the toolchange dialog work better.

I probably could add that option.

 
I think that button was intended to skip the M6 remap all together. Not sure why it is there, maybe Norbert could tell us.
I commented out the code in change.ngc, so for me it does not matter where or if the button is replaced since I am not using it.

But can I kindly ask you to consider to put all the common values from basic probe, versa probe and the parameters in the .ini file (for the gmocapy way of doing things) on one settings page? The settings page as it is has already duplicated the values that are necessary for probing.
Now there are all kinds of redundant variables and values floating around, it's hard to see what is used and what is not.
I will be happy to do all the typing and testing, as long as I get some kind of example. In my opnion this will add to the strength of the qtDragon screens and will make life much easier for people who just want to use a great screen without having to learn internal stuff. Plus it has the added benefit of making the versa probe and basic probe screens much cleaner and less overwhelming for the user.

Please Log in or Create an account to join the conversation.

More
4 years 11 months ago #227433 by cmorley
Yes I agree - that was the intention of the button - probably more useful to add it to the toolchange dialog too.

I rethink of the settings page would be very useful. it would be nice to add the remap tool change capability to basic probe too.

AFAIK basic [probe does the same things as versa probe, other then the entries for auto tool probing.

It's actually a bit of a pain as the versa probe widget would need to change based on where it is used. (it's used as a dialog styled probe screen too.)
But its possible.

I'm glad you got it working as you wanted.

There is other work going on to improve integration of auto tool probing remap in qtvcp.
I really want to get rid of any extra HAL pins that users must connect.
I added them for you just so you could get it to work in the mean time.
The following user(s) said Thank You: tommylight, ikkuh

Please Log in or Create an account to join the conversation.

More
4 years 11 months ago #227487 by ikkuh

Yes I agree - that was the intention of the button - probably more useful to add it to the toolchange dialog too.

I rethink of the settings page would be very useful. it would be nice to add the remap tool change capability to basic probe too.

AFAIK basic [probe does the same things as versa probe, other then the entries for auto tool probing.

It's actually a bit of a pain as the versa probe widget would need to change based on where it is used. (it's used as a dialog styled probe screen too.)
But its possible.

I'm glad you got it working as you wanted.

There is other work going on to improve integration of auto tool probing remap in qtvcp.
I really want to get rid of any extra HAL pins that users must connect.
I added them for you just so you could get it to work in the mean time.
 
Looking forward to a redesign of the settings page. Would be nice to have pins that are redundant removed. If a pin does a certain job you only need it once. I understand that there will be problems with existing scripts, but isn't it time to do a major overhaul and try to unify the variables?
I am following the qplasma screen efforts, they make very exciting things. But since there are no unified variables incorporating their enhancements in for example qtDragon is difficult and cumbersome.
Maybe a centralized variables depot online could be a solution, and then make sure develloppers (re)use the variables that are available.

I guess that it is in the nature of probe routines that most do the same thing, that's why they can use the same variables. It's nice though when the gcode commands are in a .ngc file and not in-line in the python handler files. That way debugging is much easier.

I used the versa probe screen in gmoccapy, so I know what you mean. Maybe some conditional code in versaprobe widget so that a context switch can be made? Or a hard fork, to make a seperate Versa Probe screen that is adapted to qtDragon, but I would prefer the dynamic way.

Is there a place where I can see the ongoing work on a probe screen? I am curious as to how that is coming along.

Chris, thank you (and all the other developers) for being flexible and supportive, that is the main reason I got things working after trying for 8 months now. I can run complete jobs now, with multiple tool changes in on file. Very happy with how it turned out.

Next I will be trying to use the Laser routines that the plasma guys have in their screen. It's awesome how they can use a skewed work piece with just two clicks of a button.

Please Log in or Create an account to join the conversation.

Moderators: cmorley
Time to create page: 0.202 seconds
Powered by Kunena Forum