Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quering printer for moving heads #1210

Closed
sarmadsiddiqui opened this issue Aug 12, 2021 · 8 comments
Closed

Quering printer for moving heads #1210

sarmadsiddiqui opened this issue Aug 12, 2021 · 8 comments

Comments

@sarmadsiddiqui
Copy link

I apologize if this is not the appropriate venue for a help question. I was unable to connect to the IRC server, so I decided to post here.

When I use the printcore library to connect to a printer using p = printcore() command, I can move the printer heads using two approaches. For the first approach, I can load a .gcode file using the loaded_gcode = gcoder.LightGCode(gcode_path), where gcode_path is the path to my .gcode file, and then print that gcode using p.startprint(loaded_gcode)

The second approach is to use the p.send(command) syntax directly to the printer. If I need to move along a complicated path, I can make some loop and keep issuing the p.send() command, which queues up commands like a stack.

When I do the first approach, I can look at the printing status by the p.printing command, which tells me that the print is still going. However, when I issue a p.send() command and then run output the value of p.printing I always get False as a value (even when the printer heads are moving). Is there any other command that can tell me the status of the printer heads when I'm using the p.send() command? Or any other approach to tell me that the printer head has arrived at the position I asked it to?

Thanks.

@volconst
Copy link
Collaborator

See
https://marlinfw.org/docs/gcode/M114.html
https://marlinfw.org/docs/gcode/M154.html
One problem is that the printer buffers move commands and replies with 'ok' before the target is reached.
The other problem is relating responses to requests - the easiest solution is slow - before sending the next command, wait for the response of the previous.

@sarmadsiddiqui
Copy link
Author

Thanks for the response. In the following code, p is the already connected printcore class instance. I tried the following command using the printcore library ():

p.send('G1 X30')
p.send('M114')`

The printer receives the first command as I see the head move, but I see no output from the second command. I also tried

k = p.send('M114')
print(k)

and the output was None

Just to make sure the board was responding, I connected to it via Pronterface, and sent the M114 command, and I did receive an output as listed in the example in the links you sent. Any suggestions about some step I'm missing when I'm using the printcore library?

Thanks again!

@volconst
Copy link
Collaborator

volconst commented Aug 12, 2021

Reading and writing is done in separate threads different from the main thread.
Use printcore.recvcb to observe responses from printer - again the callback is called in read thread.
See #1201 (comment)
There are several issues with many code snippets, check https://github.com/kliment/Printrun/issues?q=is%3Aissue+recvcb

@sarmadsiddiqui
Copy link
Author

thanks for the pointers. I was able to use one of the examples to get the printer responses back.

Is this PR #1008 already implemented, where I can wait for an okay before executing the next command?

And a second question. In the M114 documentation, it talks about M114_REALTIME and M14_DETAIL modes. Do I just send them like that: M114_REALTIME or is it something like M114 R? Neither seems to change the output (I always get projected position), which leads me to believe the SKR v1.3 board I'm using may not support these features. Is that a reasonable assumption?

And thank you so much for your time. I really do appreciate it. Speeds up the trial and error tremendously.

@volconst
Copy link
Collaborator

#M114_REALTIME is a C++ directive that you uncomment before compiling marlin firmware and flash it to the SKR board.
gsync.py from PR #1008 is not integrated in master branch. It was an experiment which I am not sure if it's worth.

@volconst
Copy link
Collaborator

If you get projected position that is not yet reached, try sending first https://marlinfw.org/docs/gcode/M400.html and then M114.

@sarmadsiddiqui
Copy link
Author

Thanks for the help btw. Didn't get a chance to comment after your tips. I did as you suggested, and it works.

For reference, I first collected my sent commands and printer responses to synchronize the command and responses, with code adopted from PR #1201. Once synced up, I sent the command M114, saved the generated response, then sent the M400 command and then the M114 command again. I waited for the printer responses to sync up (a while loop that breaks when the first M114 response equals the second M114 response. When the while loop breaks, I know the printer is where I want i to be and I can execute my commands on the main thread.

Thanks for your help again, wouldn't have figured things out without it.

@volconst
Copy link
Collaborator

Great, thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants