Rotary resolution value

Some time ago, @KGN instructed us to change the $103 value from the previous 19.753 to 79.008. I made that change. I have not been using the rotary for a while, but tried a project today. Twice, the project carved only half of the diameter of the material. When that happened, the virtualizer showed a flat project.

I’ve not solved it yet, but I did find that, in settings, there is a resolution field for the rotary. It did not change when I changed the $103 value. It still shows 19.75.

I am attaching screencaps of the two settings. Can I assume that I should change the rotary resolution value in settings to the same as the $103 value? I notice that one is measured in steps/mm and the other in steps/degree so I am not sure if they are to be set to the same value.

Does one override the other?

Did you remember to save the file with the vortex postprocessor? When I have a file show in g-sender flat it normally because I saved the file with the incorrect post processor selected.

@jpnharris tks, Jim. I did save using the vortex post. I’ve not had problems before this version of gS and the SLB combination. Also, just to make life interesting, the issue is intermittent. That is, the visualizer depiction is. So far, I can confirm that, when the image is flat, the carve only cuts half way round. I can’t confirm that it cuts properly when the visualizer shows properly, since I ran out of wood before trying it.

I’m open to other ideas if you have them. Tks.

Couple things:

  1. For SLB, we swap the A-axis EEPROM values related to rotary with y-axis values when toggling on Rotary mode rather than use settings since the SLB has dedicated EEPROM values for A-axis and we don’t need to store it elsewhere (AKA the board already has functionality that we’ve manually implemented for vanilla grbl on gSender side).

That’s why the settings value is different - that would be used for the longboard/grbl firmware if you toggled rotary mode since those eeprom values don’t exist in vanilla GRBL. Using grblHAL swaps the eeprom values instead. The A values are only used for true 4-axis, and toggling rotary mode swaps the A values for the Y values since Y is hijacked to use as A.

  1. Can you show $100-$103 and your rotary toggle state? The two states should be similar to the following:

4-axis (rotary mode off):

explanation: rotary mode is off, so eeprom values not swapped. $103 (A) is the specific degrees, $101 (Y) is normal.

Rotary mode on:

explanation: $101 and $103 has been swapped (since Y is being hijacked as A). The other 6 settings warned about are also swapped.

I’m wondering if (either through bug/user error/etc) toggling rotary did not swap the values for you correctly.

@KGN I can confirm that my values = your values. Since the odds of my issue being pilot error are so long as to be impossible :grinning: :grinning:, I have no idea what went wrong.

Seriously, though, Kevin, I’ll keep an eye on it. The more strange part is why the visualizer showed a flat project when there really was no question that I chose the rotary post.

I will continue to watch this and report back if it recurs.

Tks for your input.