Feature Request for wireless Handwheel

[awpross]

I think it may be usefull to put Ideas for the Wireless Handwheel in one thread to see what may already be implemented in future or what users may want to have.

At first, the following line of code put in the expr.txt gives some basic information about the handwheel status.
print("Mode: " , _hw_mpg_mode, " Axis: " , _hw_mpg_axis, " Value: " , _hw_mpg_value, " Delta: " , _hw_mpg_delta, " Key: " , _hw_mpg_key, " Velocity: " , _hw_mpg_velocity);


I was thinking about using that information to select things on screen while switch is in "C" position but unfortunately the "_hw_mpg_value" parameter does not change if there is no axis selected. Maybe this could be changed that the _hw_mpg_value always updates it's value using the handwheel even if no axis is selected. So I would be able to use _hw_mpg_axis==6 (which is the "C" position) and _hw_mpg_value to do something useful.


Besides that, I found some request from others and also my own requests:

- Add a section to expr.txt like #OnJog which is executed on every change of _hw_mpg_xxxx and not only when "jogging". (Makes only sense if _hw_mpg_value always changes, even if no axis is selected.) Or maybe in the handwheels.txt?
- Tool Change
- Selecting Macros from predefined list in Display and execute them.
- Changing predefined Values from list and change them with the wheel while machine running
- Display the messages, invoked by (msg, myMessage) on the handwheel too.



Would be nice to have feedback what may be realistic for next release.

I realy like the possibilities TNGv2 provides. That's realy good work!

Similar Threads:

• Wireless Handwheel question
• Mk3 and Wireless Handwheel ON SALE
• [TNGv2] - Wireless handwheel
• XHC Wireless Handwheel
• Roctech Wireless handwheel

[PlanetCNC]

1. I can create new _hw_mpg_custom parameter that will change if you move wheel while in "C" position and shift is pressed
Can you explain how would you use this?

2. I can create #OnWheel event that will trigger when _hw_mpg_custom parameter is changed

3. Macros in C position are already implemented in latest version

[awpross]

Can you explain the Macros in C position? Didn't notice that. Maybe this already meets my reqirement.


I thougt using _hw_mpg_custom to show a popup on screen (as long as there is no way to show custom messages on the wheel itself) where the user can choose from several options and select them.
Another aproach may be selecting options from a custom toolbar by highligting the selected option by using the updown state which may be possible within the scripting engine without additional programming knowledge.
Another reason may be the use to manipulate the running program. I have some realy long running programms, which may require some adjusting during runnig. For eaxmple temperature monitoring of tool which may require adjusting while running and some other stuff.


Feature request for S position:
-> Ability to change spindle speed and feed at the same time as an option. Like changing the feed and traverse speed at position "F" at the same time.

Reason: Due to temperature increasement when tool us used a long time, it is sometimes required to reduce spindle rpm and persist rpm/feed ratio even if there is no spindle sync used.

[PlanetCNC]

Some of this stuff is still on my desk and will be available in next release.

1. New parameter "_hw_mpg_custom". This changes in "C" mode if shift is hold down.
2. Expr.txt events #OnWheel. This is triggered if mpg key is pressed or "_hw_mpg_custom" is changed.
3. Ability to unassign key. Usefull if you want o use key only in #OnWheel event.
Here is an example for unassigning spindle key.

cmd: "NONE" "" num=0x000b

4. Rotating wheel in "C" Mode allows macro selection. Here is an example:

cmd: "Machine.Spindle" "Spindle" num=0x10004
cmd: "File.Open_..." "Open" num=0x10001 param=0.1
cmd: "Machine.Flood" "Flood" num=0x10002
cmd: "Machine.Mist" "Mist" num=0x10003
cmd: "NONE" "Count by 5" num=0x10006 param=5

Macros are defined with "num" attribute greater than 0x10000. They are also sorted by this number.
"param" attribute defines scaling factor for "_hw_mpg_custom" parameter. In example above, "_hw_mpg_custom" does not count by 1 but by 0.1 and last one by 5.
Macros are executed by pressing "Cycle" button.

[PlanetCNC]

One example is also this:

cmd: "Machine.Output_PWM" "PWM" num=0x10005 param=10 val="[0;expr:_hw_mpg_custom]"

This macro will set PWM duly cycle on output 1 to a value set with wheel.

[awpross]

Thats pretty cool....
Already implemented that for many macros and tool change.

May it be possible to supply a value by expression as current value for each macro? So it will not always start at 0%, but showing the current value.

It also would be nice to set formating of the value. Looks strange if I select a tool by setting a value in %.

Another cool option would be to allow execution of macro while changing the value or after changing value when shift is released. That may improve handling for some macros.

[PlanetCNC]

Please send me you your macros. I'll try to make them better.

[awpross]

Oh wow... that's great.

I have added my entire profile.

If this results in much work, dont' hesitate to contact me for financial compensation.


Currently on my ToDo-List, which can't be realized by myself in descending order (First = higher prioerity)

- Decelerating on Probing and homing ;-) (just kidding, already realized that won't be that easy)
- Tool Change with Handwheel already implemented but looks strange to select Tool as % value...
- Displaying current state in the value field for the selected macro and not starting at 0% each time.
- Tool change execution by releasing "shift" after changing the value. (If not too much work)
- Same as for Tool Change also for Coordinate System selection.
- Option to use the value while changing it. Only makes sense if it will show the actual value, maybe supplied by an expression.

- Is there a way to know which macro is currently selected in #OnWheel Expr.txt? and for which macro the _hw_mpg_custom parameter is changed?
I was thinking of that to use at a later time when my infrared temperature sensor is attached to select the "E-Stop" temperature by handwhlle.
Another Idea was to change the flight height, depth during drilling, and retract location on the fly by using variables. That is something I can easily add in the post processor. You may ask why the hell will someone ever want to change that while gcode is running.... Drill 50.000 Holes and do 50.000 tappings a day and you will know why this would be cool to have.





Just to let you know why your measurment scripts are changed and not fully functional right now:
I am currently rewriting all measurement and probing scripts to work on rotated coordinate system and to work exactly as in the Autodesk Fusion 360 Simulation. I am also writing a PostProcessor for this purpose.
Goal is to fully support all Fusion 360 Probing options for 3-Axis and that also when using rotated coordinate system and when probe origin is rotated in Fusion 360 to measure angles, nuts, edges and every thing else in every rotation and with exactly the same tool path as shown by the fusion 360 Simulation.

Am I right, that the following expressions don't work on rotated cs and axis?
towork - Converts machine coordinate to work Usage: towork(100,0) = 90
tomachine - Converts work coordinate to machine Usage: tomachine(90,0) = 100
Looks like unit and axis as parameter.... but for rotated CS it would require X Y as input and X Y as output

If that is right, Can I add own expressions for this purpose somehow?
Currently i have created the required calculation in o102.gcode but would be nice to have as expression for easier use. So this is nothing which has priority right now.

[PlanetCNC]

What about measuring scripts is not functional?

towork and tomachine use current position for other axes. They also work in rotated coordinate system.
But I can implement xy version if needed.

[awpross]

Don't worry about the measuring scripts. They are currently not working in my CNC1.rar... because i started rewriting them and i have not completed them yet.

Your measurement scripts are working.

The only thing, why I started changing them is because the Autodesk Fusion 360 expects other toolpaths for measuring. And to use automtic probing within fusion 360, it makes sense to have the same toolpath. Otherwise it would look in fusion 360 simulation as if the measurement will succeed, but in reality the probe may follow another toolpath and touch the workpiece somewhere else.

On the other side, Measuring in Fusion 360 requires the measurement script to know which angle and which coordinates it has just measured to calculate rotation and XY offset based on that provided information. Another resaon for the rewriting is the idea to measure several points and calculate workpiece position and rotation based on multiple ponts for maximum tolerance reducion.

There are also scenarios where a probing operation in fusion will adjust other coordinate systems or used for automatic tool diameter compensation. That's especially usefull on materials like plastic where the part has different measurements if the densitiy of the material is different. And if you like to mill that whith an accuracy better than 0.005, it requires probing and adjusting. That's something we do currently by hand, but I expect to be able to automate this with the new probing scripts.

I am bretty sure no one else will ever use that the way I do. But I am a kind of perfectionist and require high accurate workpiece lignment in high production volumes. So probing is one of the essential reasons why i am changing the old controller to the mk3. The old one can do porbing too, but it is slow on executing scripts and therefor it was never n option for me to use the old controler for probing.

You may notice the red workpiece in the CNC1.rar 3D-Simulation... Goal is to be able to measure every single angle and position of every line. And that's why I am rewriting all measurement scripts.

Should I mention that I have a wireless probe from vers.by ?? That also requires some special handling. That's because the probe must be switched on, the machine needs to wayit for wireless communication ready and also is required to be able to repeat a measurement if the probe loses connection while probing.

But don't worry, thats something i can easily programm myself with the scripts because I am an expierenced programmer in vb.net javascript and c#.net wih over 30 years of expirience in programming ERP Systems and realtime HTML5-Based machine monitoring applications.
Of course the scripzing language is new to me, but that's lust a question of time.

[awpross]

towork and tomachine use current position for other axes. They also work in rotated coordinate system.
But I can implement xy version if needed.

Oh i was just wondering where towork and tomachine gets the xy position.

A true X Y version would be great. I may not be able to travel to all the positions which are required for my calculations.

[PlanetCNC]

Here are examples for new handwheel features:

cmd: "Machine.Output_PWM" "PWM" num=0x10005 param=0|10|0|100 val="[0;expr:_hw_mpg_custom]"

"param" excepsts 4 numbers separated with pipe (|) character.
1. initial value
2. step
3. minimum
4. maximum

Number of decimals is automatically calculated from step value. Or you can set is manually with "size".
Example:

param=10|0.1 size=3

Initial value 10, step 0.1, number of decimals shown 3. no minimum or maximum.

expr: "exec('#Pipi')" "Pipi" num=0x10010 param=0|5|-20|20

This will execute expr.txt section named "#Pipi"

[awpross]

Can the initial value supplied dynamically? for example by using_myCurrentValue as variable?

[PlanetCNC]

No, but last value of each macro is remembered.

[awpross]

ok. thats great.

[awpross]

Tried in beta and looks good. Thank you.