Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FeatureRequest]: MetaGCode Bitwise Math #1066

Open
bdistin opened this issue Dec 5, 2024 · 2 comments
Open

[FeatureRequest]: MetaGCode Bitwise Math #1066

bdistin opened this issue Dec 5, 2024 · 2 comments
Assignees
Labels
enhancement Additional functionality, performance or other feature request
Milestone

Comments

@bdistin
Copy link

bdistin commented Dec 5, 2024

Is your feature request related to a problem? Please describe.

Missing mathematic operations that would allow some relevant programming paradigms to be used in meta-gcode.

Describe the solution you propose.

It would be great if one could define an Int and track state using bitwise math. According to the docs, you can do (bool,bool)->bool with & and |; but this would allow you to do (int, int)->int with & and | too, as well as other bitwise operations.

Describe alternatives you've considered

State tracking in MetaGcode for related states can currently be done with a vector of bools; however, the length has to be defined in advance and in likely different places in a meta gcode-base. It can also be done by writing the operations in base 10, but that becomes harder to track/easier to make a mistake.

Provide any additional context or information.

Understandably, this is a little niche, and not everyone will make use of it. But here are a couple of examples to help convey how it could be used.

While specific operators or functions are up to your interpretation as it fits within the vision of RRF; in these examples I will use operators similar to how JavaScript uses them. The table below defines the ones used in the examples, but it is not an exhaustive list.

operator operation
| bitwise or
& bitwise and
<< bitshift
|= variable |= value would be equivalent to variable = variable | value

Example 1:

Only show the message if the 3rd bit of the global is 0 then set the 3rd bit to 1 after shown.

globals.g

global tutorialMessagesDisplayedThisSession = 0

g37.g

if { global.tutorialMode && global.tutorialMessagesDisplayedThisSession & 1 << 3 == 0  }
  M291 P{"The tool is about to move over the <b>ToolSetter<\b>! You will then be presented with a jog menu to <b>Manually<\b> decide where to measure from."} S4 K{"Continue", "Cancel"} F0
  set global.tutorialMessagesDisplayedThisSession |= 1 << 3

Example 2:

Store the current pin states before disabling them so they can be restored on resume.

globals.g

global pinState = 0

pause.g

var collector = 0

while { iterations < #state.gpOut }
  collector |= state.gpOut[iterations].pwm << iterations
  M42 P{iterations} S0

set global.pinState = collector

resume.g

while { iterations < #state.gpOut }
  if { global.pinstate & 1 << iterations == 1 }
    M42 P{ iterations } S1
@bdistin bdistin added the enhancement Additional functionality, performance or other feature request label Dec 5, 2024
@benagricola
Copy link
Contributor

benagricola commented Dec 5, 2024

There's been a number of times bitwise operators on integers would have been helpful for me while writing meta gcode (similar to the above examples), and I think these will be useful when used alongside the new Modbus commands - some VFDs and other devices use bitmasked fields to store information.

It is possible to work with bitwise fields right now but it involves chaining existing maths functions.

var bitmask = 2

; Extract bits
if { mod(floor(var.bitmask/pow(2,0)),2) == 1 }
    echo { "Bit 0 set..."}
elif { mod(floor(var.bitmask/pow(2,1)),2) == 1 }
    echo { "Bit 1 set..."}
...

Edit: I think it would also be fine to add these as functions rather than operators, which may be simpler from an implementation perspective.

@T3P3 T3P3 assigned dc42 and unassigned x0rtrunks Dec 5, 2024
@T3P3 T3P3 added this to the After 3.6 milestone Dec 5, 2024
@bdistin
Copy link
Author

bdistin commented Dec 13, 2024

Edit: I think it would also be fine to add these as functions rather than operators, which may be simpler from an implementation perspective.

Yeah, I would also be fine with functions. Examples were written using a preexisting/well-defined way so that the intention was (hopefully) more widely understandable.

Like I said in the OP:

While specific operators or functions are up to your interpretation as it fits within the vision of RRF...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Additional functionality, performance or other feature request
Projects
None yet
Development

No branches or pull requests

5 participants