Hi @sszafran . It didn’t do that. No. And I think i was using a version in the http://100.xx range.
But too late. I’ve literally disassembled the mill in to its components and will be leaving France for a month in a day or two. So no more time. I’m back in late May then in hospital for a while so won’t have time again on my hands until September.
Such is life!
@Justin_Adie i use a atmega2560 with a ramps1.4 shield.
Personally i gave up a long time ago on this (will try the jpadie though).
@jlauer If he went to google+ to send a message for help, don’t you think that he checked the baudrate before that? People aren’t stupid! Instead of constantly waisting our time with stupid questions and suggestions, you should leave the support to others, who DO know what they are doing.
@Mano_Biletsky_Open_M yes, it’s likely he checked baud rate, but you never know. A baud rate being the problem has probably resolved 10% of all support questions on this forum.
I’m grateful for all the help offered. And particularly to @jlauer for nearly always chipping in and of course putting the original and continuing effort in to CP.
the issue with the Mega2560 (for those who want to use that as their grbl host) is that the bootloader waits for longer than the uno bootloader for a new sketch. but conversely something in the CP universe likes to spam the board as soon as there is a connection. So on connection/baud rate select etc, the board waits there and receives input from CP that it thinks is a sketch. CP gets no response (CP just sits there as a TFTP server essentially) and keeps on sending stuff assuming that one of these days the board will respond. but it doesn’t.
the workaround is to prevent reset. The solution is to find out what in SJPS and/or CP is spamming the board so quickly after the connect occurs.
this behaviour is also seen if you set up a mega2560 as a serial repeater for a grbl board. - it is not (of course) a grbl specific issue but a bootloader issue.
another solution would be to burn on to bare metal and remove the bootloader.
The grbl buffer starts sending ? every 250ms to get Grbl to send back position updates in near real-time. It’s probably those ? commands you’re saying get sent too early. If you connect with the default buffer and are then able to communicate, that could help prove it’s the ? commands.
Nope. It waits three seconds before requesting updates. Something else spams before that it seems.
You may be thinking of what the Javascript does. I’m thinking of SPJS. On line 38 of bufferflow_grbl.go is the Init() method. The last line of that method starts the func b.rptQueryLoop(b.parent_serport). That func writes the ? every 250 ms n2, err := p.portIo.Write([]byte("?")) with no 3 second delay.
I did not know that. or rather had forgotten it.
but yes - for sure SPJS needs to be told to keep quiet for a while with grbl-mega. and I would think the Uno does too. The optiboot boot loader has customisable timeouts between 500 and 8000 ms. but i guess it bails if it doesn’t receive the right starting sequence for a sketch upload. I think that the mega2560 bootloader must be different, and does not have the auto-bail code.
perhaps we need a clone of the buffer flow control code for grbl mega boards. but i wonder how many people use them.
Jarret Luft designed that bufferflow by copying the TinyG one and tweaking for Grbl. He also designed the initial Grbl workspace. He isn’t involved anymore from what I can tell so it would be great to get a new volunteer to own the Grbl experience.
with Luca I have reworked the gcode list, the grbl widget, the auto levelling code and started having a look at the axis widget. most changes are in the workspace (other than to the grbl widget).
Luca and I also reworked some of the flow control. I have rolled back from my experimental version to 0.94 stock. the experimental version followed the tinyg model but I kept seeing very broken lines of code there. the preparser was munching the code in some circumstances. I have not found time to repair that.
I will do what I can to polish things up and then issue a pull request so that it is in a state for someone else to take over.