Can't get a print run to move the build plate - everything else is working


Hi. Trying to set up with the Wanhao D7. So far, I’ve managed to get everything working except for moving the build plate during a print run.

Manual control of the printer via the Photonics3D UI works fine. Sending G-Code manually through the same interface works fine.

I set up a “dry run test” ink configuration, downloaded the 3DBenchy.stl and started a print - the screen shows the sequences of image slices as I’d expect, but the Z axis remains completely still. The sequence is a bit flickery which at the moment I’m putting down to it taking zero time to get through the LCD off/lift/lower/LCD on.

I’m suspicious that the Z Lift Sequence G-code isn’t working. This is what’s there - I think copied from slightly older Creation Workshop configurations (it’s very similar to code I have in CW, that does work):

M106 S0 ;Disable LED array
G1 Z(${ZLiftDist} * ${ZDir}) F{${CURSLICE} < $ZNumLiftFirstLayers?$ZLiftBtmRate:${ZLiftRate}}
G1 Z((${LayerThickness}-${ZLiftDist}) * ${ZDir}) F$ZRetractRate
; %d$BlankTime
M106 S255 ;Enable LED array

So a couple of things, I guess - first, is the above lift sequence code ok?
Second, is there a way of seeing what Gcode Photonics3D sends during a print run and what it gets back from the printer?

#2 (111.8 KB)


Quick update - worked out what was wrong; the G-Code segments provided are not appropriate for Photonic3D.

I think I have it all working now, at least on a dry run. Has taken some fiddling around and I want to test some prints first, then I’ll post the correct settings. Just wanted to say that before anyone spends too much time on it (I’m guessing none of the Photonics3D developers are using the D7!).

There is one other thing worth looking at - I can get the preview to crash quite easily just by impatiently changing layer selection and hitting Go while it’s already busy; Java runs out of heap space, throws an exception and goes 100% on a core so presumably has got stuck waiting for a dead thread. The exception is in the logbundle cwh.log I attached before.


Probably not, but keep in mind you can test the output from any gcode template with the test button to be sure. I’m assuming you don’t really want the ‘(’ or ‘)’ or ‘*’ to be sent to your printer, but since they are outside of the curlys{}, they will be sent.

Where Creation Workshop doesn’t have any sort of reason for what gets sent to the printer, freemarker does have rules. The general rule is that if it’s between the curlys or between a directive designated by a # sign then it get’s interpreted by freemarker:

For example:
G1 Z(${ZLiftDist} * ${ZDir})

will could send this to the printer:
G1 Z(.05 * -1)

Most likely the individual is attempting to send this to the printer:
G1 Z-.05

So they would want to create the following GCode instead:
G1 Z${(ZLiftDist * ZDir)}