Closed sbryan closed 8 years ago
Yep, broken on marshalling and unmarshalling by the way. Fixed both. Notice, that I did say it was tough to setup a new printer here: https://github.com/area515/Creation-Workshop-Host/wiki
...and unfortunately I see it's also bug prone.
Fixed in version: cwh-0.110.zip
Sorry, I'll keep this open for testing purposes. You can close it when you are ready.
Ah, totally spaced on the unmarshalling... duh!
And did you mean it's fixed in build 111? I'm still figuring out the build numbering thing, but from what I can see in your tree, the fixed build number is now 111.
I'll try to verify this tonight BTW, thanks
At the moment we are using Ant to run our builds. Not because we like it, but because we could set it up in a few minutes. If you've ever used the buildnumber task in Ant, it will perform the build with a version number, and then automatically increment the number in the property file to the next version. That means that your buildnumber version in the build.number file is always +1 ahead of the current version. Strange, but that's the way Ant works.
Feel free to change the whole build mechanism, but keep in mind that the build.number file is coupled with the start.sh scripts and you might have some work to do to keep the auto upgrade mechanism working.
Just noticed this is still only in your repo, not the "main" one here, right? If i'm reading start.sh correctly, when I manually run start.sh (initially pulled from the area515 repo) and pass in the "WesGilster" option, it will fetch and use your latest build, correct?
Is there a "go back" method? IOW, can I pass in "area515" and it will "downgrade" the installed version to the latest from the area515 stable repo?
Yep, that's the way I intended start.sh to work as I've documented it on the readme page. It will actually pull from any repo this way, not just WesGilster.
I'll relabel this issue as force downgrade to area515 repo.
Implemented and untested in version 0.121.
Completed and tested in cwh-0.178 with new GUI.
Downgrading has worked for quite some time...
I've recently been using CWH with one of first Draken DLP/SLP printers delivered to a backer (/me) and was encountering lots of "Internal Server Error" problems when trying to manually create printer configurations in /root/3dPrinters/...
Here's the scenario... The printer has 8 physical projector positions that it can be mounted in, ranging from 1 being the closest to the resin VAT and 8 being the furthest. Obviously (or maybe not?), the closer to the VAT, the finer the resolution of the XY but the smaller the build area.
As such, the (Draken developers) provided a set of pre-defined CW Machine profiles (.machine files) for each of the positions... awesome! They also provided a slicing profile (.slicing file). So, to effectively make print resolution selection easier, I wanted to have 8 "printers" in the CWH web interface, from which I can pick the one for the current projector position. To that end, I created the following set of configs:
Within each of the above defined
*.printer
files, the<MachineConfigurationName>
value matched one of the*.machine
file names and the<SlicingProfileName>
value all pointed to the same, single file,BasePrintProfile.slicing
.Unfortunately, I could never get this to work... I always ended up with the "Internal Server Error" message, and looking in log.err, I could see that the requested service URL was raising an exception about service URL not found (I don't remember exactly, and my logs have since been replaced :( )
The only way I could get things to work were if I created one
*.slicing
file for every*.machine
file. All*.slicing
files were identical (in fact, I didn't test it, but I suspect symbolic linking them could have worked). So, here is what I ended up with that was the only way I could get things to work:So this got me looking into the code, and I believe I've found the root cause...
In
resinprinter/server/HostProperties.java:366
I believe the call togetMachineConfigName()
should instead be a call togetSlicingProfileName()
, resulting in the following corrected line of code:Otherwise, if the intention is to actually ignore the
<SlicingProfileName>
entry in the*.printer
files, we ought to document this someplace.