@3dpandme here are some screenshots i took today-

Hi -

Edit 5/30/2021: TLDR 3-page tape together RepRap G&M Code reference Version 1.0 is below and linked here - https://git.io/JGWSJ

RepRap GCode-MCode Cheat Sheet pdf

---

I have been keeping a notepad near my printer to write stuff like the gcodes that I can not remember when I am stading in front of the PanelDue. Its pretty disorganized as of late.

It finally dawned on me that what I really want is a 'cheat sheet' or sorts. Maybe 1 page, front and back that can get laminated and slid under the printer, to be pulled out when you need to remeber how to use something to key it in. Something with print large enough to read so you don't need to use soda bottle reading glasses to glance at.

I fount this one online, and while its a bit outdated, is descent. I don't like how its like a page and a half though. Its a starting point at least.

https://www.makeit-3d.com/wp-content/uploads/RepRapGcodeCheatSheet.pdf

Anyone interested in helping me create one for RRF 2/RRF 3 ? I know that RRF 2 is no longer officially being developed, but there is still a large user base out there that I don't think we should ignore.

Something like color coded GCode entries- reguala black text for both versions, blue for RRF2, green for RRF3.

I am asking for help because I don't feel that I have enough experience to know what I don't know, and what I will need in the future.

I am sure that there are others out there who are more GCode fluent and can suggest the common, not so common and would be handy to have at your fingertips suggestions.

EDIT: Here is my start on Google Sheets-

https://docs.google.com/spreadsheets/d/1t7sre2tTz08T092pJQXnBBwlMeCLlWj1bUkufDhtY-A/edit?usp=sharing

Here is what I am thinking about for color coding options to show the differences between versions. I'm not sold on it yet, but its a start.

I am thinking the easiest way to whittle down the Mcode list is to use filters- entering 'Yes' in the second column will let us cull the list pretty quickly.

I realized that I had not updated this in a while. Its still a work in progress, but this PDF should print to US Letter landscape. I could use some help converting to SVG so it would be page independant.

Contribution/Objective Critique and Collaboration welcome.

files on git here: https://github.com/nionio6915/RRF-Cheat-Sheet

Hi all-

I'd like to request that an entry be added to the config tool and the dozuki pages for detachable probes under the endstop configuration page.

I am the developer of the Euclid Probe- a probe which is mechanically and electrically coupled through the use of a pair of magnets. The style of probe is gaining in popularity- beyond the installations of Euclid there are a few derivatives of and and imitations of Euclid and it's system.

The probe is essentialy an NC microswitch that is deployed and retracted via the M401 and M402 macros. It can be used as a Z-endstop and as a stand alone Z-probe. In RRF3 Conditional gcode used in the macros for deployment and retraction make the detachable probe robust and reliable. In RRF2, there were no logic checks and the user has to verify attachement or removal.

A corrolary device might be Johan's Allen Key probe that had a few deliberate motions to deply and retract. Those movement steps would need to be user input either by fields in the config tool, or with placeholders in M401/M402 macros to be edited later. Those macros could probably get some extra comments peppered throughout as needed.

I will admit to having some bias towards my own device, but as a class or type of hardware there is certainly a growing following. I'd like to get this catagory/group added to the config tool.

How does a new entry get considered?

What kind of supporting information do we need to provide and maintain?

Thanks in advance

Dennis P.

I would like to ask that a verbose option be added to probe commands so the trigger value gets output to the console.

Just like the output of G30 S-1 but continous/ on the fly as the machine probes insead of stopping at the trigger height.

Why? if the probe is configured with an A and S parameter, the probe will re-probe until the probe tollerance is less than the S parameter. I think it is usefull to be able to read those values.

So for example, if you invoke a P parameter for probe point numbers to level the bed via-

G30 P0 X20 Y190 Z-99999 ; probe point 0 near a leadscrew
G30 P1 X180 Y190 Z-99999 ; probe point 1 near a leadscrew
G30 P2 X100 Y10 Z-99999 S3 ; probe point 2 near a leadscrew and calibrate 3 motors

I would like to see the initial Z trigger height and sucessive probes, or at least the deviations from the reference value.

respectfully submitted,

sinneD

I threw together an Excel spreadsheet to 'draw' icons and convert the binary and hex numbers. Its semi-automatic: meaning that you might need to adjust the lines and ranges to suit.

I 'checked' it against the binary for the fan.img icon in mud's menus.

https://github.com/nionio6915/LPC1768-RepRapFirmware-Files/blob/master/icon-creator.xlsx?raw=true

It uses conditional formatting to highlight the boxes and fill them in if you populate it with a 1, and spits out the binary and hex codes.

I only set it up for up to 8 pixel and 16 pixel widths. If you adjust the rows / columns you will have to play with the array and transposes.
Its not hard, but dont be surprised if you have to tweak it a bit.

As always, use at your own risk, your mileage will vary.

@mendelevium BLTouch can suffer from inaccuracies from heat and magnetism. Anything with onbaord electronics will suffer some sort of drift at temps >80C.

full disclosure: I am the creator of Euclid Probe. you can buy a kit or roll your own from the git repo. I think you will find it suitable for your needs.

Induction type probes will also suffer from some drift at those temps. Trying to get the device close to the nozzle also creates some difficulties. Voron users have give us feedback that they switched away from those specifically becasue they melted the housing being too close to the hot end.

The limitations on it are the temperatures for the components. Most switches are rated at 75-85C. For highter temps, we have kits that have components that are good for service at 100C and 125C.

DIY solutions that rely on friction, glues and similar suffer from durability.

I am using a similar probe. You can't tell if it is a SPST or SPDT snap action swtich unless you tested to see if the switch is NC or NO. That will make a difference too. NC is prefered. Hook up a test light or DMM and check. The config is different if it active low or hgh.

What is your M574 config line look like?
https://duet3d.dozuki.com/Wiki/Gcode#Section_M574_RepRapFirmware_Num_3

@darryl123 youy can post images via the button here or just pasting them into the message body.

you might also find a service like imgur helpful- look at Desktop Website instructions

@nightowl999
do you have and H564 statements in your homing macros ?

formating: use three back ticks , the one under the ~, top left of your keyboard.

test

@MaxGyver i use 2 kinds of probes on my CNC- an aligator clip to connect to the tool/touch-off plate for Z and a baby reinshaw type probe for X-Y.

the touch off plate will probe twice for setting Z.

the X-Y probe i think will only touch once.

I am not currently near that machine but will be over the weekend. i will try to make some experiments and report back.

sinneD

@hpiz i am literally struggling with today too....

I think that Duet for a router or CNC is fine. the problem is we need to config EVERYTHING.

i was thinking that my estop button will cut motor power only, not controller power.

problem is, i think that the system will still try to move the motors with the 5V controller input power.

@chrishamm said in Question about possible firmware change:

I can confirm it works well in v3.5.0-rc.1+.

Is this documentation current?

https://docs.duet3d.com/en/User_manual/Tuning/Macros_tasks#naming-and-ordering-macros

I would like to ask that a verbose option be added to probe commands so the trigger value gets output to the console.

Just like the output of G30 S-1 but continous/ on the fly as the machine probes insead of stopping at the trigger height.

Why? if the probe is configured with an A and S parameter, the probe will re-probe until the probe tollerance is less than the S parameter. I think it is usefull to be able to read those values.

So for example, if you invoke a P parameter for probe point numbers to level the bed via-

G30 P0 X20 Y190 Z-99999 ; probe point 0 near a leadscrew
G30 P1 X180 Y190 Z-99999 ; probe point 1 near a leadscrew
G30 P2 X100 Y10 Z-99999 S3 ; probe point 2 near a leadscrew and calibrate 3 motors

I would like to see the initial Z trigger height and sucessive probes, or at least the deviations from the reference value.

respectfully submitted,

sinneD

@Joeyhershey did you get this sorted?

It took us a while to figure out the RRF behavior when developing Euclid because this wasn't well documented. The RRF2 & RRF3 examples have comments within then with regards to wrapping the gcodes and macros within M401 and M402 sets.

as dc42 explained, RRF's deploy token is checked internally, you want to be consistent with M401/M402. this advice is based on experience, not opinion.

M401 and M402 are the NIST standard gcodes for probe deploy and retract. At least thay have been the gcodes in reprap for 15 years +/- now. They call the deplyprobe.g and retractprobe.g macros. As dc42 pointed out, the associations are built in, don't rename them.

Looking at your files, you have mixed BLTouch commands and Euclid commands. I recommend that you get rid of all the old BLT stuff. I don't know how BLT works with RRF, but the M280 may be triggering the probe token as well.

you can check with something like this-
echo "Probe Value =" ^sensors.probes[0].value[0]

If you are clever, you can write a conditional gcode that could check for probe delployed or not and have that in your files.

Lastly, you might notice why the Euclid examples do not check the check the OM probe variable for deploy: we check the actual probe value to ensure pickup in case of a mis-deploy.

sinneD

@Hernicz you are still not understanding that if you dont reverse the Z axis far enough to clear the backlash/friction of the mechanical system this is not yeilding any real results. All you are measuring the relative slop in the system.

please reread my comment- i said one full MECHANICAL step of the system.

If you are trying to claim any accuracy by 'preloading' the touch probe so it does not have to travel as much, then what happens when you run over a crumb or scar in the bed?

@dc42 said in Secondary Dive height for probing:

@Hernicz I considered this and decided it was a good idea, so I've implemented it ready for release 3.5.0-rc.1.

I tested it by probing 135 points on a E3D tool changer (probing speed 600mm/min) with the M558 A2 S0 parameters used to force two probes per point. With both dive heights set to 3mm the time taken was 3min 20sec. With the dive heights set to 3mm then 0.5mm this was reduced to 2min 27sec.

1. Can you post up a summary of the trigger values please?

2. Change it to min dive height of at least a 1 full mechanical step of the Z motion system (ie, > 2mm for a 2mm lead screw) and compare those numbers.

3. What probe are you using? If you want speed, Euclid with D2F-5 switch, we've gone as fast as 500mm/sec travel speed with repeatable and predicable results. OEM says not faster than 30 operations per minute for electical component life.

@CNCModeller Did you get this working ?

I had my Diabase version connected to my Tiny-M at MRRF and people really liked it.

@Hernicz said in Secondary Dive height for probing:

@sinned6915 I do G32 with 0.001 precision with really good repeatability. Probe also set up to 0.001.

Of course if you probe with different speed or dive height the measurement will be off, but RepRap only renders the probing successful if you have the same values on two consecutive probing moves.

The purpose of this request is to lower the dive height on secondary/finishing probing moves thus speeding up the process

I disagree. That thinking is false economy.

By not reversing the Z motion system past the amount of inherent Z backlash, you are not measuring anything. All you are doing is 'measuring' the turn of a stepper motor withing the backlash amount.

Consider that your claimed 'precision' is 1/3 that of the thickness of the ink drawn with a Sharpie marker or 1/5 the thickness of a piece of lint. Measure those and then re-state your claim.

@infiniteloop i have an optocoupled relay triggerd by PS_ON pin on the Duet2 board and always on 5V power supply.

I see how you have configured the pin state for enabling the PSU, now I am wondering how to combine the two functions- the screen macro and physical button.
This could apply to say dust collection on a CNC machine too.