0xdeadbeef

1.1.3 In pevious versions, speeding up the 1st layer didn't work after removing the raft. Background was that the initial skirt (used to start extrusion outside the raft) was patched from Raft into Support and then the search for the search for the (end of) the 1st player stopped immediately when reaching the (patched) skirt. Now the skirt is patched into "1st Layer Support", so it's identified as part of the 1st layer (and thus also sped up). Note that if the raft was removed with an older version than 1.1.3, speeding up the 1st layer will still not work. 1.1.4 Raft removal kept a part of the raft when there was no initial skirt. This only happened for very large prints where Z-Suite didn't create an initial skirt. Added workaround that should work for all Z-Suite versions > 1.7.x. 1.1.5 Fixed a bug in raft removal for ZCodex format. Due to internal handling of the differential extrusion values, removing the raft caused a massive overextrusion at the first extrusion after the (removed) raft.

Released 1.1.2 Reworked raft removal caused issues with some ZCode files: raft removal would remove some part of the first layer (if they were tagged with infill instead of contour).

Relased ZTool 1.1.1 Raft removal wasn't working with generic ZCodex files (as the extrusion value is not reset to 0 by the slicer for the M200 Plus when retracting). The raft removal mechanism should now automatically use layer changes instead (note that it was originally designed before the layer command even existed). Added some comments like "support", "raft" etc. in the exported G-Code. It's not perfect as it doesn't filter out futile/double comments but then again, S3D doesn't either. This also improves import of these exported G-Code files into ZTool a bit.

Since this somehow ended in a different forum, the new version of ZTool now supports ZCodex (somewhat experimental though). See the other thread for details

I released a new version 1.1.0 of ZTool which can be found in the usual dropbox folder: https://www.dropbox.com/sh/91jdv24taxeayof/AACiBRHvH_d0FjRbo0cKEkwOa?dl=0 The main features are support for the ZCodex format used by the M200 Plus and export of G-Code. Please read the according sections ("Notes about the ZCodex format" and "G-Code export") in the RTF manual for details. Anyway, as the support for ZCodex made it necessary to rework some internals, there's the chance I messed things up. As a result, I'd consider version 1.1.0 to be somewhat experimental. Therefore, the stable version 1.0.9c is still available in parallel. Besides, I still haven't found a volunteer with an M200 Plus. So currently I can only say that Z-Suite opens ZCodex files created by ZTool without complaining (and vice versa). I'd be happy to hear from an M200 Plus owner if the printer accepts and prints e.g. ZCode converted to ZCodex (which I'd consider the safest scenario). Note that it's probably a good idea to use an offset of 170µm when converting from ZCode to ZCodex due to different initial Z heights of M200 and M200 Plus. See RTF manual for details. Also note that I currently don't plan to release a "g2z" version that supports ZCodex.

For what it's worth: I had a deeper look into the "ZCodeX" format and to my surprise, I was wrong about ConfigurationData being used for certification, so it doesn't need to be changed for ZCode patching or creation. Actually, the ConfigurationData is just what the name implies: the serialized and encrypted slicer Configuration. I'm actually not sure why it's part of the ZCodeX archive at all as it only contains information about slicer configuration which neither the printer nor Z-Suite need to print or display the ZCode. Well, Z-Suite doesn't even complain when the file is totally missing. I would assume it's only there for fault analysis (i.e. people send ZCodeX files to Zortrax to get support) but this doesn't really explain why they spent the additional effort to encrypt the file. Anyway, even if I'm too lazy right now to add ZCodeX support to my tools, I managed to patch a ZCODEX archive manually to load modified ZCcode into Z-Suite. So using 3rd party slicers on the m200 Plus seems totally possible and it actually looks like Zortrax didn't even try to block 3rd party ZCode..

The download link is still the DropBox in the very first post in this thread. I would be surprised to hear that anything relevant in the firmware changed lately or that Zortrax would try to protect the m200 against user created ZCode. The M200 Plus is a different story with its new ZCODEX format, but even this seems to still use ZCode (zipped, renamed, header stripped) internally. There's just this crypted ConfigurationData file which seems to be there to avoid tempering with the ZCode.

Unrelated to new ZSuite or firmware, but as I also looked into a bug report I received quite some time ago, there's a new version today: 1.0.9c Fixed a crash resulting from GCode which uses a negative retations value directly after setting the extrusion value to 0. Also fixed a command index issue in this context which could lead to removal of the wrong command in certain situation when resetting the extrusion value. BTW: Couldn't see any new materials at least for the m200.

Uploaded 1.0.6 Fixed a crash resulting from GCode which uses a negative retations value directly after setting the extrusion value to 0. Also fixed a command index issue in this context which could lead to removal of the wrong command in certain situation when resetting the extrusion value.

Admittedly, I have been very lazy regarding Zortrax topics lately. So I haven't looked into newer versions of ZSuite etc. Anyway, are there any issues I'd need to have a look at other than maybe displaying new materials correctly? As a side note, I also haven't looked much into "ZCODEX". At first look, it's simply a Zip archive which still contains more or less normal ZCode data named "ZCodeData" plus a backup (?) named "ZCodeOriginalData". The header was removed and replaced by some text files (UserSettingsData, ZCodeMetadata). Then there's one file named "ConfigurationData" which is most probably crypted. I kinda assumed they would take the chance to crypt the whole ZCode file. For some reason (RAM size probably), I guess they decided to just crypt one smaller file instead to certify the uploaded ZCode. Well, that's just my guess. I would suspect though that a m200 Plus wouldn't accept changed ZCode without a new "ConfigurationData". Regarding ZCode -> G-Code: ZDump could do that quite some time ago but I decided to deactivate the code for ZTool mainly not to provoke Zortrax as they made very clear that they wouldn't tolerate publishing details about ZCode and a working Z->G converter would make it very easy to reverse engineer ZCode. Admittedly, I also thought the created G-Code would be unusable on other printers. It came to my attention lately that some ZDump testers really did that. Still I think that this wouldn't be a feature for normal users (which includes myself).

@kohyarp Sorry for the late reply. I was busy with other thing and also pretty much lazy regarding anything ZCode related. Anyway, I had a very short look at your G-Code and observed some things: 1) You used a different slic3r version, namely Slic3r 1.33.8-prusa3d-win64 (you) vs. Slic3r Prusa Edition 1.38.2-prusa3d-win64 (me) 2) There is no bed temperature set in your G-Code. There should be a line like "M190 S80 ; set bed temperature and wait for it to be reached" after the fan is disabled. 3) The extruder temperature is wrong. It should be 275°C for Z-ABS but in your g-code it's 265°C. As far as I recall, this is a temperature that's not used in any Zortrax profile. I guess 10°C too low could have caused the jamming. 4) I'm not a Slic3r expert, but "; first_layer_extrusion_width = 0" and "; extrusion_width = 0" and "; support_material_extrusion_width = 0" (and many more) look wrong. Dunno what happened there, but these values are not 0 in my examples. I would guess this is somehow related to the different SW version. Anyway, keep in mind that I can't and won't support debugging G-Code files or slicer configurations. My tools simply convert the G-Code to ZCode in the best possible way and I kinda hoped that the community would do the rest (like sharing working configurations etc.). @backdoob & ffix78: don't get me wrong, but Zortrax made pretty clear they don't want me to discuss details of ZCode. Actually, I understand we have some kind of gentlemen's agreement that they tolerate my tools as long as I respect this wish. So if something can't be discussed here, I will most probably also not discuss it in private until the situation changes.

The structural analysis only seems to check wall thickness. I kinda suspect it would only complain about walls smaller than the nozzle diameter or so which Z-Suite always suppressed instead of adding a "thin walls" mode like in other slicers. About supports: e.g. when slicing 3DBenchy, the automatic support tool creates four large support structures. One at the bow, one at the stern, one around the wheelhouse and one around the funnel. Now you can remove each of these four support structures, but you can't remove parts of one of these large structures. Support structures inside the model (e.g. when printing a knob) are obviously not editable at all. At least there is no way to select them and therefore they can't be removed. Same is true for support structures hidden by other support structures. BTW: for the Inventure, editing support doesn't seem to be available at all. And yes, the percentage slider only has 4 positions: the leftmost position is 10% and the rightmost is 70%. Below that slider, there is a small text (edit) field which displays the current percentage and which features small +/- buttons. Again, when you press + or -, the percentage jumps to the next of the four steps and the text field doesn't allow editing.

I wouldn't hang my hopes too high. The slicing engine seems to be exactly the same as in Z-Suite 1.11.x. It shares the same bugs and if at all, it might be even a bit slower. The key feature are: You can manually add and delete support. Adding support seems to work fine, deleting support is much too coarse and doesn't work on hidden support. Which means you will end up having to do all the support manually instead of removing only the one you don't need. There is a structural analysis done to check wall thickness. Can't be skipped though. So actually it increases the slicing time without much benefit for me. And that's about it. People in the facebook group go wild about being able to set the infill percentage. But actually there are just four steps from 10% to 70% which equal the existing low, medium, high and maximum settings. At least the GUI hints towards selectable infill patterns in the future, but currently only the default pattern is available.

1.0.6 Fixed issue with empty retraction commands created with newer versions of Z-Suite. Improved ZCode support for Inventure. 1.0.7 Added option to increase distance between raft and first model layer. Separate speed setting for 1st model layer. Fixed: export dialog didn't keep/display setting from previous export. Fixed: export dialog didn't offer PLA and ASA profiles and therefore changed profile name to ABS.

Hm, good question. This (slightly confusingly named) error message should only occur if the imported ZCode has less than 10 layers. The error message looks like a copy&paste issue (from RaftAway to g2z), I guess the real intention was something like "Implausible G-Code: too few layers". Two suggestions: 1) Try to convert with ZTool - which shouldn't have this sanity check. 2) Upload the G-Code somewhere so I can have a look As a side note: 247.5MB seems very low. A 64bit JRE on a PC with reasonable RAM should have a maximum close to 4GB or so instead of <250MB. With a 45MB G-Code file, I wonder if 250MB will suffice. An out of memory exception of the JRE should result in shutting down the application though. [EDIT] Uploaded g2z 1.0.5 which removes the <= 10 layer check. Still, there needs to be at least one layer.