Vai al contenuto

0xdeadbeef

Membri
  • Numero contenuti

    39
  • Iscritto

  • Ultima visita

  • Giorni Vinti

    27

Tutti i contenuti di 0xdeadbeef

  1. 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 par
  2. 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).
  3. 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.
  4. 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
  5. 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
  6. 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 missin
  7. 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.
  8. 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.
  9. 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.
  10. 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 m
  11. @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
  12. 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
  13. 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 t
  14. 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.
  15. 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 45M
  16. 1.0.5 Added support for Z-PLA Pro and Z-ASA Pro and firmware 1.1.1. Reduced minimum extruder temperature to 160°C
  17. 1.0.4 Added support for Z-PLA Pro and Z-ASA Pro and firmware 1.1.1. Reduced minimum extruder temperature to 160°C
  18. Without checking in detail, I would assume this is due to a certain difference of where S3D defines the start of the layer and where my parsers does. Since I don't want to rely on layer comments (and can't in certain conditions), my import algorithm detects Z movements and adds a ZCode layer command before the Z move that moved up to the new layer. So if S3D adds a fan command just before that Z move, my algorithm will instead define it as last command of the previous layer. Which is I think exactly what happens here. Secondly, the fan speed and Z positions displayed in certain views
  19. I need to add that there could still be issues with ZCode from Z-Suite 1.6.x at least when trying to set the fan speed in raft layers. Problem is that Z-Suite 1.6 sits somewhere in the middle between the older ZCode style without any layer information and the newer ones with layer commands for each layer (including raft layers) since Z-Suite 1.6 creates layer commands only for model layers (not for raft layers). Now ZTool still tries to autodetect these layers to be able to display them in the preview. As a side effect, a (theoretical?) fan command within a raft layer would be stored wh
  20. Ah, OK, stupid me, I forgot the layer command was only introduced in Z-Suite 1.6. Falsely remembered it was in 1.5.x. So in a nutshell, the current (simple) algorithm copies all the commands for the original ZCode in a new one but removes all fan commands. While doing that, it checks for layer commands to see if the current layer fits the next one from the loaded fan profile. In that case, it creates a new fan command (with the value from the profile) after the layer command. Now as ZCode creates with Z-Suite < 1.6.x doesn't contain layer commands, this results in removing all fan
  21. I'm a bit clueless about your first example. For the 2nd one I assume Z-Suite created a 0% command at this position which ZTool didn't remove. When I think about it, it probably was a bad idea to keep the 0% entries. So I uploaded a new version 1.03c which removes all existing fan commands and adds a 0% entry automatically at the end. This will most probably help with the 2nd example. Actually I can't see how it would help with the first example. If it won't, could you upload the zcode file somewhere?
  22. Hm, I'm not sure if any of this is a problem (of ZTool). Let's try to answer in order: The fan is always 0% at startup (by definition), so it's not saved in the fan profile as it makes no sense to override. If you force a fixed 0% in Z-Suite, this might actually create a 0% fan command, but ZTool won't save it as it will only create entries when the value changes (and 0% to 0% means no change). Most versions of Z-Suite create a fixed 20% fan control after the raft even if you specify 0%. Has to do with raft separation I guess. Lately I observed fan commands inside the ra
  23. Fixed a minor glitch ("Report 0%" appended at end of ZCode when importing fan profile). -> 1.0.3b Yeah, testing sucks ;) Side note 1: you can use the preview tool to check at which layer which fan speed is used/needed. You can also use it immediately after importing a fan profile to check your result. Side note 2: If you want to calculate the layer from height, keep in mind that Zortrax is not honest about the layer heights. E.g. 90µm is really 100µm, 140µm is really 150µm and 290µm is really 300µm. You get the idea. Also the raft starts about 0.2mm above the be
  24. Uploaded a new version 1.0.3 that allows exporting/importing fan profiles to/from simple comma separated text files ("*.fpr"). First line is an identifier, followed by lines in the format <layer>,<fan percentage> Both values are integer. Note that raft layers are negative. The fan speed given for a layer will be set directly at layer entry. No need to set an initial or final 0% value. Example: ;Fan Profile -2,30 1,20 4,82 5,93 10,94 12,96 14,87 18,99 19,84 20,89 23,99 37,80 39,72 40,73 41,100 Not excessively tested as usual.
  25. About fan speed: I'm still trying to understand your use case, i.e. if you really want to override the given values completely. Like there's already the possibility to limit values and also scaling the values (down?) would be simple. About the Z movement speed: what I can say is that ZCode created by Z-Suite uses values of up to 8000mm/min for X/Y and Z movements in the fast setting ("normal" quality). In the slower setting("high" quality), the movement speed it's 5400mm/min. Beyond that I think that the firmware limits the speed anyway internally.
×
×
  • Crea Nuovo...