G-Code preview

[Clicky @clicky]

Quite nice! Well done. I am completely with you there as last night It started making java app for gcode preview (based on open source javascript on http://gcode.ws/. It is going to be (if everything goes well) more integrated so you’ll be able to see post-processed gcode as well…

BTW what app for gcode preview you’re suggesting to add for Mac?

[Mikko @sodacan]

Out of old habit I’ve been using Repetier-Host (I’ve been using it as the host app with my other 3D-printer). It’s perhaps not the most accurate of apps in visualising GCODE but gets the job done.

[Michael Gordon @mikeg]

I’ve been using Cura for yonks with my Ultimaker 1. I’ve just checked. It can import gcode and display layer data. Use File/Import model file. A legend should show up at the bottom of the screen showing progress but nothing shows of the layer data will show until you click on the icon at top right and select ‘Layers”

I’m expecting my Robox on Wednesday (ordered on 29/01/2014). Does anyone know if it is possible to create the gcode elsewhere and then import it into Automaker?

Mike.

[Clicky @clicky]

Does anyone know if it is possible to create the gcode elsewhere and then import it into Automaker?

So far no idea. Similar question - no answer - see here:

http://www.cel-robox.com/forums/topic/xxxxxxxxxxxxxxxx_robox-gcode/

Theoretically you can replace Slic3r’s command line with bash/bat script to provide gcode file from somewhere/somehow - but I am not aware if it was tested yet.

[Michael Gordon @mikeg]

@clicky Thanks - for the tip and the link.

[Mikko @sodacan]

@Clicky. I guess you already know but the post processed GCODE doesn’t look very good. We’ll need a proper GCODE viewer from CEL supporting their custom two nozzle control codes. Anyways, I decided that replacing Slic3r with a stub was still too inconvenient and felt too unintegrated. So instead, I did some quick reverse-engineering and implemented all the necessary changes in AutoMaker directly. Obviously that is something you’re not really supposed/allowed to do so I won’t be sharing any source code or binaries.

I really hope CEL can maintain a steady flow of AutoMaker updates (weekly snapshots would be ideal at this stage of development). Would be annoying if one had to implement all the cool new features by oneself :).

[Clicky @clicky]

@sodacan Yes - that is exactly what I had in mind. I have an idea how you can share it with others without causing any trouble…

“Would be annoying if one had to implement all the cool new features by oneself :).”

Actually it would be cool to do so and then eventually share it with everyone else through official channels.

[Mikko @sodacan]

@Clicky Out of respect to CEL I’m not interested in starting to collaborate on their reverse-engineered code. Also, it’d be illegal. It’s one thing to mess around with application binaries by oneself for study purposes but sharing the work is another thing entirely.

[Clicky @clicky]

I don’t think what I had in mind would represent illegal activity nor I meant to use reverse-engineered code. Definitively not sharing CEL’s code.

But I understand what you say. Sorry for asking…

[Anonymous]

@sodacan - how different are the slic3r and cura gcode outputs? Would it be very hard to substitute one for the other before post-processing?

[Clicky @clicky]

@biscuitlad “Would it be very hard to substitute one for the other before post-processing?”

Not really. One way to do it is to replace slic3r executable with shell script to invoke other program to produce gcode. However, how will AM’s post-processor find its way through ‘foreign’ gcode - I don’t know. It would be nice to have preview of that (post-processed) gcode as well and then start making experiments.

[Anonymous]

@clicky - yes, a “Roboxed”-gcode viewer would be very nice!

[Author]

Posts