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 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.
  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 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.
  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 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..
  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 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).
  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 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.
  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 (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.
  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 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.
  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 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.
  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 have a slightly different meaning. So if the Z move didn't happen yet when the fan command is requested, the Z position is correct since it still applies to the last layer - even if this is the very last command (from my algorithm's point of view). The fan graph displays the maximum Z position reached for each fan command. In the preview window the upper Z/Fan are for the actual command. Since the command slider is at 100% by default, this is the Z position and fan speed after the last command for this layer. The line shows the maximum fan speed as "Fan:" and the maximum Z position as "Z:" for the given layer. So if the fan speed command is interpreted as last command of the previous layer instead of the first command of the current layer, this would explain the above display: In layer 4, the 50% command is the last command and also the maximum value, so both values are ~50% In layer 5, the fan speed at the end of the layer is 0% (so it's 0% at the beginning of layer 6), but the maximum is still 50% since this is the entry value. BTW: admittedly, displaying "/15" if there are really 16 layers seems a bit confusing. It's means as the maximum value though, not as the number of layers. Also note that Z-Suite > 1.6 creates negative layers for the raft. So the number of layers is e.g. 8 increments higher than the maximum layer. In this case displaying "182/200" for the uppermost layer seems much worse than displaying "200/200" for the maximum even if there are really 208 or so layers in sum.
  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 when exporting the fan speed profile. But as there are no layer commands for the raft and ZCode from v1.6 is handled by the algorithm for the newer ZCode format, changing the fan speed within the raft will fail. I'm not sure if I'm motivated to rework the fan speed loading again to add another workaround. Most probably nobody will ever notice this glitch anyway.
  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 speed commands but no new commands being added. Now you might ask how saving the profiles works if there are no layer commands. Answer is that ZTool (and g2z) detects layers automatically if older ZCode or G-Code is loaded. When I think about it, this should make it possible to also handle loading fan speed profiles for older ZCode. Need to take a look at it. It's a while that I implemented that part. [EDIT] I implemented a workaround for ZCode created by older Z-Suite versions which didn't create layer commands. -> 1.0.4 All your examples work now. Note though that the one created with 1.8.x suffers a bit from storing only one fan speed per layer. However, allowing multiple fan speeds per layer would lead to lots of problems in handling. Like how to define this in a simple text file etc.
  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 raft as well (at least for HIPS profiles). In Z-Suite 1.8.x, Z-Suite introduced this weird 100% oscillations and I complained with screenshots like this (was still ZDump back then but anyway) in the official forum (search for "oscillation"). Actually these oscillations even happened with a fixed fan setting. Marcin argued this was by design to avoid pillowing. Later they admitted it was a bug at least for the fixed fan setting. My understanding is that they want to set the fan to 100% above horizontal surfaces but the algorithm freaks out on slopes. Anyway, not a ZTool issue. These jumps to 100% are really there. It's just that in reality, it's a relatively slow process as it happens from layer to layer. Also depends on the model and mainly happens on 90µm and 140µm settings with models that have slopes. But yes, this still exists in Z-Suite 1.10 (see attached screenshot)
  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 bed and each raft layer is 0.2mm in height. Furthermore note that (for whatever reason) Z-Suite creates a separate layer for the initial mini-skirt even if it's at the same height as the lowermost raft layer. -> the raft layers -8 till -1 are really only 7 distinct 0.2mm layers -> 1.4mm in height Again, the preview tool is your friend.
  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...