Page 1 of 1

CubItMod V6.05 and KISSLicer 1.6.3 release

Posted: 02 Aug 2018, 03:56
by CJWubex
I will start a new thread, as I think the previous one (relating to 1.6beta) went down into a path of changing hardware.

I am trying to use CubitMod with KISSlicer 1.6.3. However it fails with the message

"
Speed selection Error.
All the MaxSpeeds used into the Matl tabs must be 10 mm/s or more faster than the other speeds ( Perimeter, Loops, Solid, Support, Infill, Sparse Infill and Interface)
"

Delving a little into the AU3 code (Thank you Giovanni for making this available), I see that this relates to an array called

nCubeitModMax

This seems to be read from the BFB header according to a key

CubeitModMax_Key

And this key is set to:

$CubeitModMax_Key = "; destring_suck_speed_mm_per_s = "

(This happens during a call to GetPrimeSuck)

Now destring_suck_speed_mm_per_s appears in the start of the (original) BFB file where the material properties are listed.

If I run a simple STL file through KS1.5, CubItMod6.05 works. If I use 1.6.3, it does not, even though destring_suck_speed_mm_per_s is there in both files.

(see attached ZIP where I have the BFB file for 1.6.3 and the BAK file from 1.5)

Any ideas why it does not get read properly?

Chris

Re: CubItMod V6.05 and KISSLicer 1.6.3 release

Posted: 02 Aug 2018, 04:58
by CJWubex
Oops - now to answer my own question (at least partially).

destring_suck_speed_mm_per_s does not actually appear in the 1.6.3 BFB file, hence why it cannot be found.

So, what should be used for the maximum speed?

Re: CubItMod V6.05 and KISSLicer 1.6.3 release

Posted: 02 Aug 2018, 09:08
by pjr
Unfortunately, this is what happens when old programs rely on comments which may not always be present.

Best thing to do is to add the comments near to the start of the file. A real PITA, as you will have to do this every time :( unless you can file a way to post-process the file to add them.

Peter

Code: Select all

; destring_suck = 0.04
; destring_prime = 0.2
; destring_suck_speed_mm_per_s = 50

Re: CubItMod V6.05 and KISSLicer 1.6.3 release

Posted: 03 Aug 2018, 02:35
by CJWubex
I am not sure I would really consider these as comments. They are not a programmers comment to themselves, but a dump of the KISSlicer parameters. So in this case CubeItMod relied on a KISSlicer parameter that seems to have been removed between 1.5 and 1.6.3. Anything that relies on a particular parameter will break when that parameter is removed, of course (*).

Actually I could add the lines like you suggested by using the 'Prefix' feature under the Printer G-code tab, so it would be automagically added to the BFB code. However CubeItMod expects it to be under the materials setting for each extruder, so it is not in the right place and does not occur for each extruder. So it need some more clever way to add the code (but this is not impossible).

However, hacking the BFB file to add the necessary lines (and then removing the error condition that CubeItMod give when it realises you are using 1.6.3 and not 1.5) gives a further problem, with a window popping up labelled "ERROR M108 S0" with text "No G1 Line". Comparing the BFB files I see that 1.5 never has this M108 S0 command (which seems to set the speed to zero), but 1.6.3 often has it followed by M101 (turn extruder on). So basically CubeItMod 6.05 cannot handle this.


(*) Actually I have never been particularly happy with CubeItMod having to abuse normal parameters, and even made a feature request for a 'free' parameter space to allow this sort of hacking in a more robust way: viewtopic.php?f=13&t=827 However I guess this was never implemented...

Re: CubItMod V6.05 and KISSLicer 1.6.3 release

Posted: 03 Aug 2018, 05:36
by pjr
CJWubex wrote:I am not sure I would really consider these as comments.
Any line beginning with a semi-colon is a comment and should be treated as such.

I was also caught out by this when writing the post-processor for the Prusa "original" + MMU.

I soon learned that, as a programmer, should any required setting be unavailable or obsolete, then it requires a sensible default.

Very clever to use the Prefix G-code, but you could try to use the Material G-code section. It may then appear in the right place.

It really does sound as though a simple post-pre-processor would be the best option. This is something I could do, but I just don't have the time at the moment :(

Peter

Re: CubItMod V6.05 and KISSLicer 1.6.3 release

Posted: 20 Aug 2020, 15:19
by mpohlman
I know it is a long shot posting to an old thread, but I am unclear on how to get around this error. If anyone could assist, I would appreciate it. Just need to know where to add the three lines of code to fix this issue. Using Cubeitmod 6.05 with kisslicer 1.6.3.

Re: CubItMod V6.05 and KISSLicer 1.6.3 release

Posted: 30 Sep 2020, 15:57
by Giovanni V.
Cubeitmod 6.05 was developed with Kisslicer 1.5 beta 2.20 and should be used with that version, unfortunately into the new versions of Kisslicer the developer changed the way the program write the comments and as Cubeitmod use the comments to find the informations it needs, it can't work.
You can find here the source of Cubeitmod 6.05, if someone has time it's possible to adapt it to the new Kisslicer's comments.
Cubeitmod source.zip
(62.69 KiB) Downloaded 209 times