search

winder / Universal-G-Code-Sender

A cross-platform G-Code sender for GRBL, Smoothieware, TinyG and G2core.
http://winder.github.io/ugs_website/
GNU General Public License v3.0
1.91k stars 768 forks source link

Add support for Marlin firmware #1080

Open breiler opened 6 years ago

breiler commented 6 years ago

Feature request

Add support for Marlin controllers: http://marlinfw.org/

It may not be the first alternative for CNC machines as it's mostly focused on 3D printing. But the firmware supports commands for controlling spindles or lasers. The Marlin community is large and their controllers are widely available and also runs on a plain Arduino Mega. Could be a great alternative for DIY hackers.

These features needs to be implemented:

vMeph commented 6 years ago

that would be lovely to have support for marlin @breiler one feature i would love to see in UGS is the ability to import .brb files directly from autodesk eagle into UGS like ChiliPeppr uses https://github.com/chilipeppr/widget-eagle would that be possible at some point?

breiler commented 6 years ago

Added new issue #1081

danriches commented 6 years ago

Hi, how's the Marlin support going? I wish I knew Java so I could help as I really need Marlin support on a RAMPS 1.4. I've tried the plain old GRBL with an Arduino Uno and it was awful, kept crashing and a PITA to calibrate etc. Marlin on a Mega with RAMPS is just perfect but finding a g code sender is nigh on impossible. Do you also know of anything that would work in the interim? Keep up the great work by the way, this software is The One I want to use and once working is the only one I'll use.

Cheers, Dan

breiler commented 6 years ago

It's going slow... :(

I might get a couple of hours next week to work on it. But it requires a lot of work to get all features in place.

danriches commented 6 years ago

I totally understand, if I wasn't so ridiculously busy at work I'd learn java and have a go at helping out, but unfortunately I've a very short deadline to produce a piece of hardware and being the sole hardware developer it's overwhelming :(

Great work by the way, love what you've done so far and it's great with my mini laser engraver!

Dan

andy-hnq commented 4 years ago

I've done a very bare bones version of the stuff needed to make UGS work with Marlin.

https://github.com/andy-hnq/Universal-G-Code-Sender/tree/marlin

As far as I can tell the main challenges (apart from me being a newbie both at Marlin and UGS) seem to be...

What works?

What doesn't work or is flaky?

What am I using?

Use at your own risk. No warranty!

breiler commented 4 years ago

Awesome, I'll try to free up some time and have a look.

I also made an attempt to get this working. But as you mentioned, real time commands would have been really helpful. Also, I couldn't get the machine coordinates or the work coordinate offsets to work.

andy-hnq commented 4 years ago

Cheers. I have not attempted to deal with machine vs work coords. At the moment wherever the cutter is when you connect is 0,0 so I just start from wherever I am or else jog to where I want to be and then disconnect and reconnect to zero the coordinates. Crude I know but it works for me.

andy-hnq commented 4 years ago

Having read a bit more about Marlin's command buffer I tried a change to limit the outstanding commands to 10 in an attempt to make it less flaky when not in single step mode.

I thought that had fixed it. My test job didn't make any obvious shortcut moves... or so I thought.

After running a few times and half noticing that one move looked not quite right I finally managed to catch it in the act of being wrong. It doesn't have the same issue in single step mode.

So it seems improved but it's still not right. It's now missing fewer steps but it's not fixed.

I also messed up the git branch so had to recreate it.

andy-hnq commented 4 years ago

I just pushed a commit.

I've tried some more debugging of the non-single step command loss and added some logging to check what is happening.

I confirmed that my 10 outstanding command limit seems to work as intended. I've changed it so that it is no longer bending the communicator class pause semantics but that wasn't the cause of the problem.

I discovered that the M108 command was incorrectly being sent twice and fixed that.

I also noticed that the first skipped command was sent immediately before the M108 so I have altered the communicator so that it immediately pauses sending when an M0 is sent.

My test job now gets further before hitting an issue but then it not only skips a move but seems to mess up the coordinate position too - almost as if the move happened... except it didn't so the finishing point is offset by the distance of the lost move but M114 reports 0,0 at the end of the job.

My test job still works OK in single step mode.

carneeki commented 4 years ago

Glad to progress on this - I'd love to ditch OctoPrint for my Trinus (which I have put Marlin on after wiping the factory firmware).

Will be happy to help test for printing.

andy-hnq commented 4 years ago

Cheers. If you are happy to build from the sources using 'mvn package' then you should be good to go.

My machine is a CNC miller with steppers on X and Y and nothing else, so a printer is quite a different beast.

At the moment I'm thinking that the non-single step flakiness is primarily related to M0/M108 pause/resume. I'm intending to try a change to make UGS wait for the active command list to drain before sending an M0 that it finds in the g code script but haven't had time to try that yet.

andy-hnq commented 4 years ago

I had another try at fixing the lost moves issue. No joy I'm afraid.

My UGS branch now delays sending M0 until the active command list is empty.

My test job has an M0 near the start and one near the end - these are prompts for me to lower the cutter at the start and raise it at the end. I had thought that the early sending of the second M0 was causing the problem but it seems not - I took the second one out of the script and it made no difference. It seems to be the first M0 that is causing the problem (the job works fine if there are no M0 commands).

In desperation I tried disabling EMERGENCY_PARSER and reflashing the Arduino. This causes it to complain that M0 is not recognised. UGS still sends M0 and M108 and the job runs OK (effectively my changes to the M0 handling mean that UGS is implementing the pause instead of Marlin).

I'm out of ideas just now for ways to get M0 pause/resume to work reliably when not in single step mode and with EMERGENCY_PARSER enabled in the Marlin build.

mron commented 4 years ago

What are the minimum commands/behavior that would need to be implemented in Marlin to make this UGS work?

andy-hnq commented 4 years ago

What are the minimum commands/behavior that would need to be implemented in Marlin to make this UGS work?

I guess it depends on your machine and the work you want to do. I can't answer that for everyone but I am still using my branch and it's doing the job for me just fine but my setup is very simple - X and Y steppers only, 'classic UI' only. I have not done any more on this since my previous post but if anyone is waiting on something that is easily do-able then please say so and I will give it a try. I have no way of testing stuff that my mill can't do though (e.g. limit switches)

andy-hnq commented 4 years ago

Sorry just re-read your question and realised you were asking about Marlin changes not UGS changes. In general the issue seems to be that Marlin is not so strong on async behaviour, for example being able to find out the current coordinates in the middle of a move, pause in the middle of a move or be able to reliably queue a bunch of commands and work through the queue with the same end result as if the commands were sent one at a time. I am definitely no Marlin expert though so it's quite possible that I'm just doing it wrong. If so then constructive input would be very welcome :)

mron commented 4 years ago

Thanks for replying. I'm not a Marlin expert, but I have modified it a few times for special projects. If you can give me a spec for new behavior and/or commands I'll see if I can implement them. List them in order of importance. I have added emergency codes in the past.

mron commented 4 years ago

I'm asking for "better" support, not perfect. I'm not an expert in Marlin or CNC.

andy-hnq commented 4 years ago

So in terms of commands, this is probably a good place to start (com.willwinder.universalgcodesender.GrblUtils) ...

/**
 * Grbl commands
 */
// Real time
public static final byte GRBL_PAUSE_COMMAND = '!';
public static final byte GRBL_RESUME_COMMAND = '~';
public static final byte GRBL_STATUS_COMMAND = '?';
public static final byte GRBL_DOOR_COMMAND = (byte)0x84;
public static final byte GRBL_JOG_CANCEL_COMMAND = (byte)0x85;
public static final byte GRBL_RESET_COMMAND = 0x18;

These are single byte 'commands' with GRBL and work immediately and regardless of whether the controller is busy or idle. The commands don't necessarily need to be identical in Marlin... provided that there is a way to do the same thing.

Priority-wise, I'd say status, pause/resume and then reset. I have never used the other two AFAIK.

As I've said in the thread above, the other thing I could not get working properly was the ability to queue and execute multiple commands reliably. For my own machine sending one command at a time doesn't make it do the job less well or even slow things down as far as I can tell. I assume that the capability to queue multiple commands is there for a reason... so knowing the 'use case' that requires this would be good.

mron commented 4 years ago

I’ll look at the status command and see what’s returned. Pause and resume will be trickier. The machine will need to decelerate and accelerate properly to keep the step count. Queuing commands might have something to do with motion planning. I’ve never looked into that part of the code.

On Sep 6, 2020, at 11:42 AM, Andy notifications@github.com wrote:

So in terms of commands, this is probably a good place to start (com.willwinder.universalgcodesender.GrblUtils) ...

/**

  • Grbl commands */ // Real time public static final byte GRBL_PAUSE_COMMAND = '!'; public static final byte GRBL_RESUME_COMMAND = '~'; public static final byte GRBL_STATUS_COMMAND = '?'; public static final byte GRBL_DOOR_COMMAND = (byte)0x84; public static final byte GRBL_JOG_CANCEL_COMMAND = (byte)0x85; public static final byte GRBL_RESET_COMMAND = 0x18; These are single byte 'commands' with GRBL and work immediately and regardless of whether the controller is busy or idle. The commands don't necessarily need to be identical in Marlin... provided that there is a way to do the same thing.

Priority-wise, I'd say status, pause/resume and then reset. I have never used the other two AFAIK.

As I've said in the thread above, the other thing I could not get working properly was the ability to queue and execute multiple commands reliably. For my own machine sending one command at a time doesn't make it do the job less well or even slow things down as far as I can tell. I assume that the capability to queue multiple commands is there for a reason... so knowing the 'use case' that requires this would be good.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/winder/Universal-G-Code-Sender/issues/1080#issuecomment-687866678, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABE67N37VDMFFOUV6NE44E3SEPJZ5ANCNFSM4FKAQ7MQ.

mron commented 4 years ago

Hi Andy. I’m working on getting this to work without losing steps. A few days before I started an identical projected was completed. This one uses quickstep(), so it will lose steps, but it’s functional.

I don’t know if any of it will be folded into Marlin, but it’s a good start.

Ron

Here’s the link:

https://github.com/fedetony/Marlin/tree/bugfix2.0.xautoreport

On Sep 6, 2020, at 11:42 AM, Andy notifications@github.com wrote:

So in terms of commands, this is probably a good place to start (com.willwinder.universalgcodesender.GrblUtils) ...

/**

  • Grbl commands */ // Real time public static final byte GRBL_PAUSE_COMMAND = '!'; public static final byte GRBL_RESUME_COMMAND = '~'; public static final byte GRBL_STATUS_COMMAND = '?'; public static final byte GRBL_DOOR_COMMAND = (byte)0x84; public static final byte GRBL_JOG_CANCEL_COMMAND = (byte)0x85; public static final byte GRBL_RESET_COMMAND = 0x18; These are single byte 'commands' with GRBL and work immediately and regardless of whether the controller is busy or idle. The commands don't necessarily need to be identical in Marlin... provided that there is a way to do the same thing.

Priority-wise, I'd say status, pause/resume and then reset. I have never used the other two AFAIK.

As I've said in the thread above, the other thing I could not get working properly was the ability to queue and execute multiple commands reliably. For my own machine sending one command at a time doesn't make it do the job less well or even slow things down as far as I can tell. I assume that the capability to queue multiple commands is there for a reason... so knowing the 'use case' that requires this would be good.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/winder/Universal-G-Code-Sender/issues/1080#issuecomment-687866678, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABE67N37VDMFFOUV6NE44E3SEPJZ5ANCNFSM4FKAQ7MQ.

mron commented 4 years ago

I'm still working on the M0 feed hold. I have some questions. When M0 ( ! ) is issued and later resumed, where is the previous state kept? When a resume command is recv'd Marlin should finish the interrupted command? Should it go back to the position it was at when interrupted, or should it continue from it is when told to resume?

Since Marlin queues up commands, does UGS know what commands have been completed? How do the Marlin controller and UGS stay in sync?

BTW: Marlin 2.0 does support realtime position query with the right Configuration options.

define M114_DETAIL // Use 'M114` for details to check planner calculations

define M114_REALTIME // Real current position based on forward kinematics

and use M114RD

mron commented 3 years ago

I have a version of Marlin which supports GRBL single letter commands "!" and "?". I have a working quickstop that doesn't lose steps saves command and move buffers and restores them. UGS is telling me "Grbl has not finished booting". What is it waiting for?

winder commented 3 years ago

Try adding the startup string: https://github.com/winder/Universal-G-Code-Sender/blob/50e4bc471c1de429324a2e4e076411ea14bf74b6/ugs-core/src/com/willwinder/universalgcodesender/GrblUtils.java#L82

On Sat, Mar 13, 2021, 6:49 AM mron @.***> wrote:

I have a version of Marlin which supports GRBL single letter commands "!" and "?". I have a working quickstop that doesn't lose steps saves command and move buffers and restores them. UGS is telling me "Grbl has not finished booting". What is it waiting for?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/winder/Universal-G-Code-Sender/issues/1080#issuecomment-798228838, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA6URI7AJBJ4M6WQKVO7IDTDM7MNANCNFSM4FKAQ7MQ .

andy-hnq commented 3 years ago

I have a version of Marlin which supports GRBL single letter commands "!" and "?". I have a working quickstop that doesn't lose steps saves command and move buffers and restores them. UGS is telling me "Grbl has not finished booting". What is it waiting for?

Which UGS branch are you running? The main branch or the Marlin branch? If you have the Marlin branch then you should be able to set the firmware dropdown to 'Marlin' (see screenshot). The branch has a class 'MarlinUtils' in the same package as 'GrblUtils' that recognises the Marlin responses.

ugc-marlin-ss

It would also be good to know which Marlin version is the starting point for your changes.

I havent touched the UGS or Marlin code for a few months but if you are still having problems then I will dig into the code and try to figure things out. My most recent commit was a merge of changes from the main branch soon after your messages last September. This branch should be the best one to use...

https://github.com/andy-hnq/Universal-G-Code-Sender/tree/marlin-sep2020

BTW, I am still using UGS+Marlin on my milling machine and it's still doing the job for me.

mron commented 3 years ago

I was running latest version from the homepage download. Not the GitHub version. Here's my Marlin fork: https://github.com/mron/Marlin/tree/bugfix2.0.xautoreport. It has !, ? working. Restart also works with "R000". I'll add '~'. I'll try your version of UGS.

This is setup for a PC. How do I get it to run on a Mac?

andy-hnq commented 3 years ago

Java is cross platform so if you get the JDK for the Mac plus Maven (the build tool) then it should build and run. I have never used a Mac myself so can't do more than tell you the theory though.

mron commented 3 years ago

I'll try it out. The Marlin fork is raw. I've only tested it with simple, short samples. I'm trying to get UGS working so I can push it. If you try it let me know how it goes.

andy-hnq commented 3 years ago

Cool. It's probably best to just get the fork to build and talk to Marlin first before thinking about any changes.

I had a quick look at the code to refresh my memory...

The GRBL real time commands are sent by the following methods...

Then the replies are handled by com.willwinder.universalgcodesender.MarlinController.rawResponseHandler(String)

All of the above have direct equivalents in the MarlinController class

Currently the Marlin fork uses M114 for status checks (and only when Marlin is idle). This is done on a time interval basis from com.willwinder.universalgcodesender.MarlinController.createPositionPollTimer()

This is called by

The raw response handler also deals with the replies to the M114 commands.

HTH

I'll see if I can persuade your Marlin to install on my Arduino... but will need some time to refresh my memory about how to do that... it's been a while.

mron commented 3 years ago

Compare your Configuration.h and Configuration_adv.h with mine. I uploaded the config files for my machine, be aware of that. I think the main changes are in Configuration_adv.h. Look for:

define EMERGENCY_PARSER

// Support realtime commands: S000 State, P000 Pause, R000 Resume

define REALTIME_REPORTING_COMMANDS

// Send machine status reports while moving and status reports GRBL style

define FULL_REPORT_TO_HOST_FEATURE

mron commented 3 years ago

Power just went out. Look at Configuation_adv.h. Look for:

define EMERGENCY_PARSER

define REALTIME_REPORTING_COMMANDS

define FULL_REPORT_TO _HOST_FEATURE

On Mar 13, 2021, at 9:00 AM, Andy @.***> wrote:

 Cool. It's probably best to just get the fork to build and talk to Marlin first before thinking about any changes.

I had a quick look at the code to refresh my memory...

The GRBL real time commands are sent by the following methods...

com.willwinder.universalgcodesender.GrblController.requestStatusReport() com.willwinder.universalgcodesender.GrblController.pauseStreamingEvent() com.willwinder.universalgcodesender.GrblController.resumeStreamingEvent() Then the replies are handled by com.willwinder.universalgcodesender.MarlinController.rawResponseHandler(String)

All of the above have direct equivalents in the MarlinController class

Currently the Marlin fork uses M114 for status checks (and only when Marlin is idle). This is done on a time interval basis from com.willwinder.universalgcodesender.MarlinController.createPositionPollTimer()

This is called by

com.willwinder.universalgcodesender.MarlinController.MarlinController(MarlinCommunicator) com.willwinder.universalgcodesender.MarlinController.rawResponseHandler(String) The raw response handler also deals with the replies to the M114 commands.

HTH

I'll see if I can persuade your Marlin to install on my Arduino... but will need some time to refresh my memory about how to do that... it's been a while.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

mron commented 3 years ago

What command does UGS send while it’s waiting for the “Grbl” string?

andy-hnq commented 3 years ago

What command does UGS send while it’s waiting for the “Grbl” string?

It doesn't (with Marlin selected as the firmware). I ran it in the debugger just now to make sure. Marlin sends a bunch of info to GRBL when it boots. The first command sent by GRBL is M114 when the timer fires after a few seconds.

mron commented 3 years ago

Ok, I’ll put that in.

On Mar 13, 2021, at 11:30 AM, Andy @.***> wrote:

What command does UGS send while it’s waiting for the “Grbl” string?

It doesn't (with Marlin selected as the firmware). I ran it in the debugger just now to make sure. Marlin sends a bunch of info to GRBL when it boots. The first command sent by GRBL is M114 when the timer fires after a few seconds.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/winder/Universal-G-Code-Sender/issues/1080#issuecomment-798772496, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABE67NY6MVI44TPLY6KAKG3TDO4LVANCNFSM4FKAQ7MQ.

mron commented 3 years ago

I got your UGS/Marlin running. I get a null pointer error when I connect.

java.lang.NullPointerException at com.willwinder.ugs.nbp.core.actions.ReturnToZeroAction.isEnabled(ReturnToZeroAction.java:76) at com.willwinder.ugs.nbp.core.actions.ReturnToZeroAction.lambda$UGSEvent$0(ReturnToZeroAction.java:69) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764) at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136) [catch] at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

I'll look into this. The USG console is showing what Marlin is sending out:

Grbl 0.9 Grbl 0.9 ...

I picked version 0.9 out of the air. Would you show me what your Marlin is outputting at boot?

mron commented 3 years ago

My Mac has java version 9. Does that matter?

mron commented 3 years ago

Here's more info: INFO [com.willwinder.universalgcodesender.model.GUIBackend]: Exception in openCommConnection.

There was one error during man install: [ERROR] Browserslist: caniuse-lite is outdated. Please run the following command: npm update

I wonder if it's a permission problem?

breiler commented 3 years ago

I have not read through all the comments here but I noticed this in your branch @andy-hnq that would cause @mron's error: https://github.com/andy-hnq/Universal-G-Code-Sender/blob/marlin-sep2020/ugs-core/src/com/willwinder/universalgcodesender/MarlinController.java#L71

You could just return the instance created here: https://github.com/andy-hnq/Universal-G-Code-Sender/blob/97a069f94683f58cda0da83676c53457c2968800/ugs-core/src/com/willwinder/universalgcodesender/MarlinController.java#L32

The capabilities-object would need to be populated with the supported features to enable those buttons in the GUI: https://github.com/andy-hnq/Universal-G-Code-Sender/blob/marlin-sep2020/ugs-core/src/com/willwinder/universalgcodesender/CapabilitiesConstants.java

mron commented 3 years ago

Thanks for responding. I really want UGS and Marlin to work together. I'm pretty sure I can get the hooks that are in Marlin and add a few more to make this work. When working with Java, does the JDK version matter? I'm using JDK 9.

Also, I've never used mvn. I made the changes you suggested on my local copy. "mvn install" seems to be the compiler. It seems to do a lot of repeat installing when only one file was modified. Is there an mvn install short cut?

mron commented 3 years ago

BTW, Your suggestion worked!

andy-hnq commented 3 years ago

I'll have a look at the error later. I'm not sure what the minimum Java version will be for UGS but I suspect that JDK 9 will be OK.

The UGS Maven build seems to take a long time for me too. Part of the time is spent running unit tests. There are options to change what the script does but I haven't messed with them myself. I just go and make a drink while it does its thing. When messing with the code I use an IDE (Eclipse in my case but I think UGS is more set up for NetBeans). The IDE just builds the code that I changed and I can run and debug the thing straight away.

andy-hnq commented 3 years ago

I got your UGS/Marlin running. I get a null pointer error when I connect.

@breiler is correct - the getCapabilities method is returning null. It was auto generated by the IDE and I have not written a more sensible version. I will do so.

But... I'm not seeing an NPE when I connect.

I will look further but it does occur to me that serial comm support is one of those areas where the cross platform guarantee may run out so this could be related to running on a Mac - I'm not saying that is certain but it is a possibility. It's not something I can check out but maybe someone else has experience of running UGS on a Mac?

Normally UGS would complain that it cant find any comm ports though... just thinking out loud.

I picked version 0.9 out of the air. Would you show me what your Marlin is outputting at boot?

I copy/pasted the text below from my UGS window after connecting. I have not messed with Marlin to make it 'pretend' to be GRBL - it's just the standard Marlin output. The M114 is sent a few seconds after boot. The M114 is not critical to making it work - it just requests Marlin to report the position so that UGS can update the UI fields.

**** Connected to COM3 @ 115200 baud ****
start
echo:Marlin bugfix-2.0.x
echo: Last Updated: 2019-11-18 | Author: (none, default config)
echo:Compiled: Dec  1 2019
echo: Free Memory: 5786  PlannerBufferBytes: 1120
echo:Hardcoded Default Settings Loaded
echo:  G21    ; Units in mm (mm)
echo:Filament settings: Disabled
echo:  M200 D3.00
echo:  M200 D0
echo:Steps per unit:
echo: M92 X200.00 Y200.00 Z200.00 E500.00
echo:Maximum feedrates (units/s):
echo:  M203 X100.00 Y100.00 Z40.00 E25.00
echo:Maximum Acceleration (units/s2):
echo:  M201 X200.00 Y200.00 Z100.00 E10000.00
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P200.00 R3000.00 T400.00
echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>
echo:  M205 B20000.00 S0.00 T0.00 J0.01
echo:Home offset:
echo:  M206 X0.00 Y0.00 Z0.00
echo:PID settings:
echo:  M301 P22.20 I1.08 D114.00
echo:Backlash compensation:
echo:  M425 F0.00 X0.00 Y0.00 Z0.00
>>> M114
[verbose] X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0
ok
mron commented 3 years ago

That's interesting. I just pushed a version that pretends to be GRBL. I put that in before I used @breiler fix. I'll take it out and see if I connect. The '!' has a slightly different output than M114. [verbose] X:0.00 Y:0.00 Z:0.00 E:0.00S_XYZ:3 S_XYZ:# is supposed to be the grbl status number. It's very unreliable right now. It's something I'll fix.

'!' should work any time, not just at idle. When I ran my tests the visualizer did not update as the job progressed. Can you look at that?

mron commented 3 years ago

I took out the fake grbl message. USG connected fine.

andy-hnq commented 3 years ago

Cool. Can you run G code and move steppers now?

mron commented 3 years ago

Yes!

andy-hnq commented 3 years ago

Excellent. I dont yet have my Arduino re-flashed but will look at that later on. Need to take care of some household tasks for the next few hours.

mron commented 3 years ago

I meant '?' should work any time

andy-hnq commented 3 years ago

Yes. I get that... I need to get your Marlin onto my Arduino before I can offer much more help but I wont have chance to look at that until later.

mron commented 3 years ago

If you have time, I'd like to work together on this. I think we can progress pretty fast. I'm pretty free right now, let me know when you have time.