Spindle speed as PWM issue. Speed for pen up not working. Speed for pen down works.

[hamppi]

Hi. Is there some explanation for pen up working always on same speed even on parametr change? Can it be somehow overwritten somewhere else in GRBL or is ib a bug? Pen down works correct and changes with parametr.

When using pen up from Control/Jogging https://user-images.githubusercontent.com/31763713/114950147-22eb7180-9e5b-11eb-93d6-d1e375cab2c5.MOV

When using pen down from Control/Jogging https://user-images.githubusercontent.com/31763713/114950158-27b02580-9e5b-11eb-951d-c8832ff8f6da.MOV

Btw thanks for impementing ramp enabled.

[svenhb]

Edit.... The possible PWM range is defined via grbl setting $30 and $31. The settings in this window should be within this range:

There is no setting for the servo speed, but perhaps you switched on laser mode $32=1 which causes some confusion. In Laser mode $32=1 each G0 move causes a PWM=0 output and a G1 move set back the original PWM value.

Also the simultaneous use of the Z-Axis and tool change may cause errors, becuase for a tool change, usuallay the spindle will be switched off (PWM=0)...

[hamppi]

$30 and $31 should be ok < $30=1000 (Maximum spindle speed. Sets PWM to 100% duty cycle.) < $31=0 (Minimum spindle speed. Sets PWM to 0.4% or lowest duty cycle.) Laser mode off < $32=0 (Enables laser mode. Consecutive G1/2/3 commands will not halt when spindle speed is changed.) Tried turning off Z-Axis but no changes.

But now I get what you mean. So basicly I cannot use Z axis and servo separatly from one board anyway? Just wanted to achive some small movement on rc-servo for the ink injection and use stepper motor for Z. Or is there someway?

[hamppi]

Is it possible to block only pen-up for rc-servo only somehow and keep it for stepper up/down and for rc-servo only down?

[svenhb]

Z-axis and RC-servo can work together - I did it here - Z as tangential axis: https://grbl-plotter.de/index.php?id=tangential-knife You may switch off "Spindle speed as PWM" but use And put in your PWM commands (Pen-up = "M3 S50", Pen-down = "M3 S550")

Is it possible to block only pen-up for rc-servo only somehow and keep it for stepper up/down and for rc-servo only down?

It's the solution I wrote above. But when should the rc-servo go up?

[hamppi]

Thanks a lot for the advise! But seems I just messed up and havent updated to the latest hex *.f so it was main issue that was making servo and stepper copy each other moves.

I found some other strange thing if I put spindle speed to 0 in tooltable it will write 500 to gcode anyway with mark it goit from tooltable (nothing is 500 in my tooltables) but when overwriting it in "Spindle speed / Laser pwr." it will create a gcode with the specified number and all is fine. May be its just a 0 that makes it.

[svenhb]

Only if Tool table is enabled:

And "from tool table" (a) is enabled: The value from the tool table will be taken. Otherwise the original value (b) will be taken. (And this only for real spindle commands, not RC-Servo pen-up/-down)

[hamppi]

Ok, thanks a lot. Just one more question and just close it or I can never stop... ) main issue problem seems to be just my hex file problem.

When caming to "call subrouting" plotter always go to Z safe value is there a way to avoid this feature so that it would keep Z same as it was and "call subrouting". For dot paint its a bit of confusing couse if I use devide method it will dot to same place 2 times and I use subrouting only for ink injection with servo like:

(make injection) M3S550 G4 P0.001 M3S525 ( %STOP_HIDECODE )

[svenhb]

I don't know your setup.... On which point you call the subroutine? "Goes to Z safe" so I assume you may use tool change functions? When do you use Z-axis and when servo?

[hamppi]

I call it every 12 units passed. So basicly call it depending on length passed everytime - I dont change the tool at all. An Im otherwise trying to avoid going to Z safe before subroutine (Im manually removing from gcode now but I wonder if something is wrong in my options just) Z is used for brush up/down and Z coordinates and servo is used for adding ink to the brush, my test setup is like this looking -

May be I just get it wrong how it should work but every soubrouting is having pen up/down before and after in gcode

G01 X100.780 Y99.616 (0.5 until subroutine) G01 X100.806 Y99.854 (0.3 until subroutine) (count 1) G01 X100.859 Y99.885
(Pen up: Z-Axis) G00 Z5.000 ( Z feed from tool table) M98 P99 (call subroutine) G90 G0 X100.859 Y99.885 (Pen down: Z-Axis) G01 Z0.000 F1000 ( Z values from tool table) G01 X100.939 Y99.933 F5000 ( XY feed from tool table) G01 X101.177 Y99.907 (11.9 until subroutine) G01 X101.256 Y99.774 (11.7 until subroutine) G01 X101.256 Y99.616 (11.5 until subroutine) (Pen up: Z-Axis) G00 Z5.000 (PU Z feed from tool table) G00 X99.854 Y102.738
(Pen down: Z-Axis) G01 Z0.000 F1000 (PD Z values from tool table) G01 X100.065 Y102.658 F5000 (11.4 until subroutine XY feed from tool table)

[svenhb]

I checked the Code: the subroutine call ist surrounded by pen-up and -down calls. I will add a checkbox to this Setup-Dialog, to allow disabling this feature...

[svenhb]

Btw nice built. How do you refill the syringe? After one subroutine call it is empty?

[hamppi]

I checked the Code: the subroutine call ist surrounded by pen-up and -down calls. I will add a checkbox to this Setup-Dialog, to allow disabling this feature...

That would be great! Yes, It is like this, just thought its may be there is somewhere else option already for that.

Btw nice built. How do you refill the syringe? After one subroutine call it is empty?

Thanks! I refill it manually just put the end inside of ink pad and pull it ) but there is no much need in refill couse its using really small amouth of ink each time of subrouting call - I figured the smallest possible speed for the servo and also added a pause between on/off servo P0.01 inside subrouting call - so the move of the servo is smallest I could achive. Here is video, might be not easy to notice it moves - https://user-images.githubusercontent.com/31763713/115117538-be89f880-9fa7-11eb-81c2-9701d653619d.MOV

Sure I would be happy to use stepper motor in the injection part but there is no more stepper outputs on the board and changing board or adding separate arduino board for that is a bit too complicated for the first tests.

[svenhb]

Now the pen-up / -down can be switched off: https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1579_publish.zip I didn't check the output, hope it works as expected.

[hamppi]

Hi Managed at last to check! Seems to work fine, thanks!

Had some strange behavior of the build a bit thought, it was stopping to respond without any error or anything and after reopen also, only working solution was to open 1.5.7.7 version it started working, close it, open 1.5.7.9 again then it worked again. Mb its just some bag, I will open other ticket if continues with more details.

[svenhb]

BTW. there is a button to restore all saved settings to default:

[hamppi]

Thanks. Ill try, but it really seems a strange issiu 1.5.7.3 seems to be stable and 1.5.8.0 seems to get dead after reset and doesnt start even after reopen, but if I open 1.5.7.3 and the open 1.5.8.0 it starts working again (0o) will check if I can figure out more on this. I have some other question and not to create mulple I post it here may be. On checking the probe with A5/ground with trggering I get this -

G38.3 Z-20 F200 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! < ALARM:1 Hard limit has been triggered. Machine position is likely lost due to sudden halt. Re-homing is highly recommended. [MSG:Reset to continue] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Missing 12 Real-time Status Reports per 10 seconds

So when I connect A5 and ground it triggers hard limit... what am I doing wrong? Shall I use other hex than grbl_v1.1f_Servo.hex this one for the probe?

If I turn off hardlimits in the RealTime status report I can see it triggers

<Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0|WCO:0.000,0.000,0.000> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Ov:100,100,100> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y> <Idle|WPos:28.000,65.275,0.000|FS:0,0|WCO:0.000,0.000,0.000> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Ov:100,100,100> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y|WCO:0.000,0.000,0.000> <Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y|Ov:100,100,100> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0> <Idle|WPos:28.000,65.275,0.000|FS:0,0>

But when I try to use it without hardlimits it just passes through when using G38.3 Z-20 F200 so I get -20 Z resault.

My standart $$ looks like this

< $0=10 (Sets time length per step. Minimum 3usec.) < $1=25 (Sets a short hold delay when stopping to let dynamics settle before disabling steppers. Value 255 keeps motors enabled with no delay.) < $2=0 (Inverts the step signal. Set axis bit to invert (00000ZYX).) < $3=1 (Inverts the direction signal. Set axis bit to invert (00000ZYX).) < $4=0 (Inverts the stepper driver enable pin signal.) < $5=0 (Inverts the all of the limit input pins.) < $6=0 (Inverts the probe input pin signal.) < $10=0 (Alters data included in status reports.) < $11=0.010 (Sets how fast Grbl travels through consecutive motions. Lower value slows it down.) < $12=0.002 (Sets the G2 and G3 arc tracing accuracy based on radial error. Beware: A very small value may effect performance.) < $13=0 (Enables inch units when returning any position and rate value that is not a settings value.) < $20=0 (Enables soft limits checks within machine travel and sets alarm when exceeded. Requires homing.) < $21=1 (Enables hard limits. Immediately halts motion and throws an alarm when switch is triggered.) < $22=1 (Enables homing cycle. Requires limit switches on all axes.) < $23=0 (Homing searches for a switch in the positive direction. Set axis bit (00000ZYX) to search in negative direction.) < $24=25.000 (Feed rate to slowly engage limit switch to determine its location accurately.) < $25=500.000 (Seek rate to quickly find the limit switch before the slower locating phase.) < $26=250 (Sets a short delay between phases of homing cycle to let a switch debounce.) < $27=1.000 (Retract distance after triggering switch to disengage it. Homing will fail if switch isn't cleared.) < $30=1000 (Maximum spindle speed. Sets PWM to 100% duty cycle.) < $31=0 (Minimum spindle speed. Sets PWM to 0.4% or lowest duty cycle.) < $32=0 (Enables laser mode. Consecutive G1/2/3 commands will not halt when spindle speed is changed.) < $100=80.000 (X-axis travel resolution in steps per millimeter.) < $101=80.000 (Y-axis travel resolution in steps per millimeter.) < $102=400.000 (Z-axis travel resolution in steps per millimeter.) < $110=5000.000 (X-axis maximum rate. Used as G0 rapid rate.) < $111=5000.000 (Y-axis maximum rate. Used as G0 rapid rate.) < $112=1000.000 (Z-axis maximum rate. Used as G0 rapid rate.) < $120=500.000 (X-axis acceleration. Used for motion planning to not exceed motor torque and lose steps.) < $121=500.000 (Y-axis acceleration. Used for motion planning to not exceed motor torque and lose steps.) < $122=200.000 (Z-axis acceleration. Used for motion planning to not exceed motor torque and lose steps.) < $130=450.000 (Maximum X-axis travel distance from homing switch. Determines valid machine space for soft-limits and homing search distances.) < $131=450.000 (Maximum Y-axis travel distance from homing switch. Determines valid machine space for soft-limits and homing search distances.) < $132=45.000 (Maximum Z-axis travel distance from homing switch. Determines valid machine space for soft-limits and homing search distances.)

Thanks in advance!

[svenhb]

<Idle|WPos:28.000,65.275,0.000|FS:0,0|Pn:Y>

Pn:Y indicates, that Y limit switch was triggered. Perhaps you made a mistake in wiring? Do you use a CNC-shield? Perhaps failure in layout. (Z-end stop spindle enable are switched, probe is not at any pin: http://svenhb.bplaced.net/?CNC___Fraese_3)

Perhaps try to set $5=1 to get rid of the 1st problem (hard limit) - Pn:Y should not appear anymore if the switch is not triggered.

Default pin-out: https://github.com/gnea/grbl/wiki/Connecting-Grbl#grbls-pins Deafult limit-switches are "normally open": https://github.com/gnea/grbl/wiki/Set-up-the-Homing-Cycle#home-switches-pins-and-wiring

[hamppi]

Yes I use a cnc-shield. Oh Does it mean probe is nowhere then... and I cant get it there somehow, only board switching? I also checked all other pins and got resaults only on 2 of them, seems both not to be probe: <Hold:0|WPos:38.313,130.462,0.000|FS:0,0|Pn:H> <Idle|WPos:38.313,130.462,0.000|FS:0,0|Pn:S>

[svenhb]

The schematic I found - this shield was made for grbl 0.9, so spindle and Z-limit are switched... Probe = A5 Don't know where this connector is...

Input Pin State:

• Pn:XYZPDHRS indicates which input pins Grbl has detected as 'triggered'.
• Pin state is evaluated every time a status report is generated. All input pin inversions are appropriately applied to determine 'triggered' states.
• Each letter of XYZPDHRS denotes a particular 'triggered' input pin. X Y Z XYZ limit pins, respectively
• P the probe pin.
• D H R S the door, hold, soft-reset, and cycle-start pins, respectively.

Example: Pn:PZ indicates the probe and z-limit pins are 'triggered'. Note: A may be added in later versions for an A-axis limit pin.

[svenhb]

The pin assinments for limit and probe are the same for grbl-original and -rc-servo version https://github.com/gnea/grbl/blob/master/grbl/cpu_map.h https://github.com/cprezzi/grbl-servo/blob/eggbot/grbl/cpu_map.h

[hamppi]

Thanks! That helped a lot. Its true the cnc-board pins are somehow messed up on the output pinpad, but Ive found A5 on the main board and it works fine with it and returns P with stop and Z hight in com console. I didnt really know how the hard limit work, but now got it, may be also a good thing to add.

[svenhb]

BTW: https://github.com/gnea/grbl/wiki/Two-Axis-System-Considerations#limit-switches

[hamppi]

BTW: https://github.com/gnea/grbl/wiki/Two-Axis-System-Considerations#limit-switches Thanks! But got a bit used to control manually all limits already. Not still sure its worth time to make the limit switchs atm.

But found some problem with subrouting and adding a height map to graphics.

So in basic without subrouting (brush refresh) height map adds just fine as it should be, taking few seconds just -

But whe I try to add subrouting and do the same it will take forever to be added or removed and will never be (as I see it and think - the subrouting is shown on the graphic plot as circles - so on adding height map it also starts to calculate hetigh map for those circles of the subrouting, that is for sure no need for at all in this) So is there a way to avoid heightmap adding to subrouting code or how can I add may be subrouting to an exiting gcode I created with heightmap correctly (like in firs pic)?

[svenhb]

I never tried height-map with graphic import... In principle the subroutines will be resolved (code will be inserted, where subroutine is called), before the height-map will be applied.

[svenhb]

Probably I don't take care about G53 and G91 when applying the map - will check

[svenhb]

Here I don't resolve the subroutines, the result looks different: https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1581_publish.zip

Finally I think the 2D-View may not show the real result, becaue I hide G53 code from any calculations and display, assuming it's only used for tools, buts in my "brush-refresh" scripts I mix normal and G53 code....

[hamppi]

Ok. My mistake. I tried with G53 added for the stir brush code and it works fine just takes way more time then without this part in code G53 G91 G01 X0 Y0 F4000 ( stir brush inside cup ) G53 G02 X0.000 Y0.000 I8.000 J0.000 G53 G02 X0.000 Y0.000 I8.000 J0.000 so I thought the grbl-plotter actually not responding but it does! So its just was my missunderstading how the G53 works.

Also was working with surface scan and some idea I had is that it would be cool when you press on the scan surface to move not only XY but also Z or may be to print Z value somewhere on screen, otherwise one need to go to the file to check the param, or is there other way to get Z?

[hamppi]

And also would great to have option for "Insert subrouting only on begin of path" so that it then block the measured subrouting insert. Thought I could just make it too big but its limit is 1000 :( encreasing it to some 1 000 000 would also work similar.

[hamppi]

Or shall I create separate topics in suggestions for that?

[svenhb]

"Insert subrouting only on begin of path"

For what this is needed?

encreasing it to some 1 000 000 would also work similar

Making this box bigger is the esiest change :-)

[hamppi]

"Insert subrouting only on begin of path"

For what this is needed?

encreasing it to some 1 000 000 would also work similar

Making this box bigger is the esiest change :-)

Was also ok with /pen down/ add code

[hamppi]

But I faced some strange thing in subrouting. What is this line starting with G90 G00 there for? It always comes after subrouting even when I have pen up/down unchecked and the biggiest truble is that surface height is not getting applyed to it, just wonder where does it take this Z = 0 information hmm.

[svenhb]

Looks like a pen-down command. Is your "Z-Height engrave" value =0? Should not appear, if this is not enabled - I will figure out.

[svenhb]

Main problem, I never tried subroutine together with applying a height map.

Subroutine: question is, how to proceed after a subroutine?

• upto now I sent a "G90 G0 lastCoordinates" after the subroutine - to be sure to continue the path... The G0 is a problem when applying the height map.
• now (if pen-up/down before/after subroutine is disabled) I send a "G90 G1 lastCoordinates"

Hope this helps with the problem: https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1585_publish.zip

[hamppi]

Hi, thanks for fast fix! But it seems to be strange a bit, it works with pen up/down checked fine but it somehow bugs with no checked after the height map apply process. Like picture down And this with checked, no Z=0 anymore What could be wrong? Just in case svg and map file. Will it work with you, may be its just I messed up smthng. 2qDFa0Jk6_h1.svg.txt plate_23cm_3.map.txt

[svenhb]

I can't reproduce the data - it starts with the hatch-fill, you may use: Can you also upload the export of the machine settings and the subroutine you use?

[hamppi]

Sorry for a long reply. Machine Setting GRBL-Plotter_20210707_133949.ini.txt Subrouting I was using one as simple as that, so It should not be connected to it may be thats why I thought its sort of a bug: (get color) G91 A30 ( %STOP_HIDECODE ) Other one would be script_brush_Lines_OnlyRefreshColor.nc.txt

And also I cant use something like this in my subrouting: G02 X0.000 Y0.000 I8.000 J0.000 G02 X0.000 Y0.000 I8.000 J0.000 It would work fine in tool change script but with subrouting it has same rasault visually as in pictrue up. Not a big deal I just avoid G02 atm but may be can be usefull.

[svenhb]

Just some backround info - hope it helps: Tool change scripts: path will never be shown in 2D-view because the code is not inside the editor. Subroutine sripts: path can be hidden via key-comments:

( %START_HIDECODE )
GCode
( %STOP_HIDECODE )

It may helps. I think you forgot the ( %START_HIDECODE )