I use my Snapmaker 125mm/125mm/125mm
It’s USB connection appears to My MacOSX Laptop as a serial port.
Installing a network serial port redirector would allow the Snapmaker Software to print across the network to a Raspberry PI3B+. When you send a print job to the, I would like OctoPrint to save the GCODE to archive it .
That configuration would allow reprints to be done using the OctoPrint software.
So...
Hopefully I've understood this setup. So then you're trying to capture the GCODE file—as streamed—so that it's archived. (This would be so that reprints can be done.)
Honestly, the job is still selected after it's just finished. You could start it again, having cleared the print bed.
But a benefit could be as a form of audit, I suppose.
I just don't like that you're conscripting a MacBook here for the duration of the print job (which in some cases might take a day or so).
If instead you have two Raspis then it sounds a lot like my man-in-the-middle rig that I talked about earlier, minus the second physical serial port. It's probably worth the effort.
There are two things that I am struggling with:
1: printing to a psuedo serial port directed to a OctoPrint/OctoPi
2: on the fly exchanging the Y and Z axis' in the GCODE stream
A little clarification is needed here.
Snapmaker is directly connected to a Raspberry PI3B+.
That allows the MacBook to disconnect after it has streamed the GCODE.
On the MacBook, the streaming output is directed to a serial port on the Raspberry Pi 3B+ that is made available over the network. ( What software is needed to create that pseudo serial port on the Mac link to the Raspberry PI3B+ ? ) The software uses a dropdown menu to select from the existing ports listed in /dev/
The Snapmaker allows a configuration that controls a pair of linear actuators but only on the Z axis. I would like to utilize that ability but on the Y Axis. ( that requires to exchange "Y" and "Z" axis' in the GCODE as it is streamed.
Trying to capture the GCODE file—as streamed—so that it's archived. (This would be so that reprints can be done.) There have been jobs that have failed for some reason and I would like to restart them at the point that the failure occurred.
Oops, it looks like I got the order wrong there.
| MacBook | Raspi | Printer |
|---|---|---|
| "master" /dev/something virtually ---> | "slave" /dev/something | |
| /dev/ttyAMA0 serially over USB --> | USB Type-B port |
In theory, I gave you the link before for virtual serial.
This page might help to understand a little better what's going on. Hopefully, I'm not sending you off on a wild goose chase.
I'm pretty sure that OctoPrint only includes a short list of possibilities in that drop-down list. So you'd need to adjust the Settings to include trying other options like these exotic device names.
Stepping back from all this, I'm not 100% convinced that a second computer is required. What if there is some service that runs on the Raspi which presents the new pseudoterminal to the printer but has OctoPrint attach to the /dev/ptm0 perhaps? In fact, if this works any number of man-in-the-middle activities could happen to include... job resumption upon loss of power.
I'll eventually put some time into this; just not today.
Normally, I would just write a Go language CLI app to do post-processing of the GCODE file, programmatically swapping the Y/Z for something like this. And then I'd send the modified GCODE to the printer. Honestly, command line goodies like AWK could do this if you're into terse UNIX commands.
Gina,
I think we now have the same concept. I would agree that we only need one Pi computer running OctoPrint
| MacBook | Raspi | Printer |
|---|---|---|
| "master" /dev/something virtually ---> | "slave" /dev/something | |
| /dev/ttyAMA0 serially over USB --> | USB Type-B port | |
| /dev/ttyAMA0 serially over USB --> | USB Type-B port |
|Run some sort of program or script ||
|To make it windows or mac portable ||
|It probably should be some flavor of ||
|Python, pyserial and listen for ||
|a bonjour announcement from the Pi and ||
|Create a pusedo serial to network from the ||
|Mac to the Pi. ||
| | |
|Running the SnapMakerJS program using the dropdown menu to select where the GCODE output is directed to.||
|| On the Pi run a service to|
||To accept a serial stream via an|
||network connection, parsing the |
||stream to manage incoming GCODE|
||and alter X, Y and Z attributes from |
||the input stream and replace the |
||alter X, Y and Z attributes in the |
||output stream to the printer.|
||InputX = OutputX|
||InputY = OutputZ|
||InputZ = OutputY|
Note that OutsourcedGuru = Michael and foosel = Gina, btw. I'm just a mod on here. She might actually know how to do all this, I dunno. I'm more of the I.T. guy-turned-programmer so I know a few different things.
I'm sure there's a solution waiting to be found and/or programmed in this space. Myself, I was looking to insert another Pi into the serial conversation in order to do some digital rights management activity but this new idea sounds more promising, I think.
Gina,
I would like to know if you have any suggestions as how to do this.
I would like to run SnapmakerJS on my MacBook Pro using a virtual USB connection to a Raspberry PI Running OctoPI/OctoPrint with a Snapmaker 3in1 plugged into it the Pi.
I would plan to install https://virtualhere.com/usb_server_software on the Pi.
And install https://virtualhere.com/usb_client_software on the MacBook.
The isn't clear is that if doing that would allow OctoPrint to manage the GCODE sent to the Pi connected Snapmaker, Start,Stop,edit, reprint, etc.
Further I would ask, if there are other software installations that would make this a more effective environment.
Again, Thanks for making these things possible.
..jpw J P Watters
I currently have not since I have my hands full with a ton of other stuff (1.3.11, 1.4.0, plus the usual day-to-day ops madness), sorry.
Gina,
This looks like an either or situation.
Installed https://virtualhere.com/usb_server_software on the Pi.
And installed https://virtualhere.com/usb_client_software on the MacBook.
Running OctoPI/OctoPrint with a Snapmaker 3in1 plugged into it the Pi.
The Snapmaker is actually a serial port device /dev/ttyAMA0
SnapmakerJS on my MacBook Pro using a virtual USB connection to a Raspberry PI
Octoprint will not share the serial port. Either Octoprint connects to ttyAMA0 or it can be made available via /dev/cu.wchusbserial120
Is there a way for SnapmakerJS to connect to a "virtual serial port" on the raspberry pi such that when the SnapmakerJS send GCODE to the local /dev/cu.wchusbserial120 on the MacBook, that the GCODE ends up being collected by OCTOPRINT and it passes the GCODE on to the Snapmaker on the Raspberry PI /dev/ttyAMA0
Such that printing to the SnapMaker is "queued" to the actual Snapmaker printer. If the job failed, filament out etc, that the job could be restarted/edited to finish the job by managing it using OCTOPRINT's web interface.
..jpw J P Watters
You might be able to use socat to connect together both /dev/cu.wchusbserial120 to a virtual port on the Raspberry before OctoPrint tries to connect with the virtual port.
socat /dev/cu.wchusbserial120,raw,echo=0 SYSTEM:'tee in.txt | socat - "PTY,link=/tmp/ttyV0,raw,echo=0,waitslave" | tee out.txt'
In theory, this would capture the input/output of /dev/cu.wchusbserial120 to in.txt/out.txt as well as tee'ing it over to /dev/ttyV0 which OctoPrint might connect to.
Interceptty looks like there's a make in the installation so you might be able to go to school on this or use it, as is.
This is getting real close to accomplishing the end goal.
So how do I send serial data and populate the octoprint GCODE instance.
Is there a snippet of python code to send a code file to a serial port that delivers the "GCODE" to the Octoprint GCODE instance? And then if there some was method to start printing the GCODE when the transfer was complete
Some of your terminology is confusing me a bit.
"So how do I send serial data and populate the OctoPrint gcode instance?"
OctoPrint normally sends the serial data to the printer.
I assume that you might mean: "Within the slicer (SnapMakerJS) after I have a GCODE file, how do I get it to OctoPrint?"
I'm starting to get confused about what goes to what. If instead you're trying to use SnapMakerJS to stream the GCODE to the printer through the Raspberry Pi then I kind of wonder what's the purpose of OctoPrint here? Oh... it's so that the Z/Y are swapped.
My Apologies for my struggle with getting the terminology correct.
"Within the slicer (SnapMakerJS), after it creates a GCODE File, SnapMakerJS will send it to a serial port.
Within OctoPrint, it probably has an array for storing the GCODE it will process. Normally a file is uploaded into OctoPrint and then sent to the serial port of a USB connected printer. ie typically /dev/ttyAMA0
I have successfully installed and run the virtualhere USB server on the OctoPrint Raspberry Pi, and installed and ran the virtualhere client on the MacOSX computer.
Was able to run SnapMakerJS and set the printer output serial port to /dev/cu.wchusbserial110
SnapmakerJS sent the GCODE to the network serial port and the VirtuallyHere USB server sent that code to the actual physical USB serial port, the 3D printer processed it correctly. Success with network printing!!
What python code would allow the manipulation of the GCODE itself on the fly.
Is there an example of python code that would allow each line of GCODE to be evaluated and manipulated say to replace Z with Y, Y with Z,
I've annotated your quote below with some modifiers to make this slightly easier for anyone trying to understand:
To the best of my knowledge then, you bypassed OctoPrint's control over any ports. In theory, OctoPrint wasn't also Connect'd at the time you did this (since earlier, you were complaining that it wouldn't share). Unless this was the case, in which you could mention something like "I noted from the OctoPrint -> Terminal screen that the gcode commands where streaming there, too".
We haven't established yet that OctoPrint is involved in this. Is it? (Is it also connected to /dev/ttyAMA0?