Jpadie issue - slow jog using X, Y buttons on the interface.

Jpadie issue - slow jog using X, Y buttons on the interface.

Hiya, just upgraded to GRBL v1.1 and it seems to jog very slowly. Am I missing a setting somewhere?

Thanks

Yes, I have the same issue.

If you switch it to inches it works properly. So I’ve been doing that. Switch to inches for large movements and back to me
mm for small movements.

Have you noticed how much smoother the steppers sound with Grbl 1.1?

The jog feed rate is set at 200. This was inherited from the original grbl interface. I can parameterise it if people want. You will be limited of course by the acceleration settings in grbl.

I also note that the click to job from the 3d viewer does not work. No idea why.

Switching to inches really should not make a difference. Interesting that it is.

Whatever solves it :). It’s just dead slow at the moment. In other news. With my cnc x pro v2 grbl 1.1f I had the same problem as I had with chilipeppr and 0.9 today. I pressed the hold button and after a few different nc files and hold and resumes it just goes mad and goes on of a random arc.

Keep an eye on the axis widget. I often saw the coordinates reset to machine coords (ie losing work coordinates). If that happens then you’re stuffed.

What i ended up doing is taking a note of the work coordinates whenever i pressed hold. If they had changed before or after a reset then i would set the work coordinates back manually.

This seems to be a bug in grbl not CP. Although noone has reported it yet.

Odd that we are on v1.1 now and no ones reported it. I knocked up a temporary spoil board and dust boot which means every now and again I probably have to hold the Machine more than most - Someone gave me a huge job and this has highlighted that I really need a proper dust boot and board.

Well. I didn’t see the coordinate loss occur when using ugs. So it may be something caused by the cp ecosystem. It also may be, in my case, because i was mostly seeing complete loss of serial comms which may have been due to a hardware problem. When the comms are lost the positioning is lost.

This is where i gave up. There became too many variables and i was not sufficiently motivated to continue trying to resolve them when my main use case is making PCBs and i can get them done in China for $1 a board if prepared to wait…

You mention that when coms are lost positioning is lost. I’ll keep an eye on what I am doing. It could be that I am inadvertently putting my machine to sleep or when my Mac isn’t used for a while after the display sleeps the network sleeps. I hadn’t considered this. :roll_eyes:

I have had that problem too Ryan. When milling i suppress sleep mode and even the display sleep mode in the energy pane on my mbp.

Yeah. I disabled sleep mode, tried cutting a circle, pressed hold, resumed, switched to a different app and it went off on a circle in the opposite direction. It’s almost like it rotated the remaining co-ordinates by 90 degrees.
missing/deleted image from Google+

Were you checking the axis widget whilst you did that? It is suggestive of the coordinates being lost during the hold/resume cycle.

Also run sjps with the -v switch and note the time that you hold and resume. Then check the verbose log. My bet is you will see the coordinates being lost by grbl.

I wasn’t as at the time I didn’t think. Just before it did go haywire I thought I am sure those co-odds just jumped to different numbers. Will do when I get a chance. Yesterday my MBP took a nose dive. The backup hadn’t completed successfully, it’s also encrypted! :sob: Had to rip the drive out, put it in an external enclosure, boot from internet recovery, unlock it, connect via smb to my NAS and run a clone to back it up before a reinstall. 500gb of it! 8 hours so far. :sob: Pretty mission critical at the mo too! Gonna get a 64Gb USB, install all my cnc apps and windows with parallels just in case it happens again.

I added the ability for you to change the jog feed rate @Ryan_Turner ​. Just click on the field in the grbl widget and change as you like.
Note that currently it does not adjust to mm/inches. So it is units/min. If you set it in mm and then change to inches then expect to hit the max acceleration for your motors. This could be catastrophic if z jogging: beware.

If anyone thinks this is a bad UX then i’d like some suggestions as to what would be better. I have some time this evening and can make adjustments.

I have also been looking at how the units are implemented and frankly it is quite bitty. I have wanted to force standardisation on the UX so that display = G20/G21 = reporting but there are a number of widgets that interact and all do things differently. Eg the grbl widget, the gcode widget, the axis widget and the 3d renderer all seem to have their own way of sorting out the units. It will take some time to create a standardised approach.

Hiya, that works. However, strangely if I tell it to move from zero by 1mm now, it gives me a positional feedback of 0.39 on all axis??! This is with a reboot too!

That sounds like an inches Vs mm issue. Perhaps your grbl controller is reporting back in inches? What do the position strings look like in the serial widget?

If you issue $13=0 do the numbers look right?

I also got a weird issue with jpadie. $13 always goes back to 1 (inches). I restart grbl and it always come back as $13=1, I must issue $13=0 manually every restart… Units always report “-” and the axes are always in mm. Any clues? BTW thanks for the support! It’s really appreciated! :smiley:

When the controller is connected it queries the grbl settings.

If you have previously worked in inches then it would be normal to have $13=1. If you were working in mm then it indicates that the $13=0 command was not properly received by the controller.

Settings commands are written to eeprom and will survive resets.

There is an anomaly at the moment where the controller can override the workspace. This can occur if you have a mm piece loaded and then connect a controller that is in G20 mode. I have not coded for that use case and I have not fully sorted out the different widgets that all do different things with units.

Three solutions for the meantime:

  1. Go back to grbl 0.9 and the grbl workspace
  2. Issue a G21 command manually once the controller is connected (or vice versa)
  3. Load the gcode file after the controller is connected.

Nb make sure you’ve flushed the cache and refreshed the browser as I was working on the units a couple of days ago.

I’ve connected directly to the controller and issued a $13=0 command. Its not reporting the movement correctly. I always load the gcode file afterwards and that doesnt seem to make difference. I’ll try issuing the G21 command. Incidentally, is realtime tracking of the toolhead workign in Jpadie?

Providing all the units agree the toolhead should track fine.

Feel free to send me the current config of your grbl and the gcode you are working with. I will see whether I can replicate the issue.