Re: CODEX: Utility to Encode/Decode CubeX/CubePro print files (and remove filament dependencies)

[Ron Konkoma]

Unfortunately, I suspect that is entirely possible...  The firmware might just refuse to run unless a chipped cartridge was installed (unlike the CubeX)...

However, it might be worthwhile for someone to create a super small BFB file to use as a test.  This might help to absolutely confirm they were required some sort of chip in place (unlike the CubeX).  If someone has the time, I might try:

1.  Create a very small print using the CubePro slicer (*.cubepro)
2.  Decode the file to BFB format
3.  Eliminate as much print activity as possible.  Repeatedly Delete stuff -> Encode->Re-Test until you get a real small BFB text file that works when encoded.  (...maybe just a linear squirt on the print bed)  Note that no printer header or directives (^...) should be altered/eliminated at this point - just print commands.
4.  Once a real small BFB print file is created (and works when encoded) it might be a good idea to post it here so multiple folks can use it for testing and experimentation.
5  THEN try tweaking/deleting various printer headers and directives (^.....) in the test file to see how much of that crap can be removed and if any of these might enable the ability to use filament without a cartridge/chip...

Maybe I'm just re-stating the obvious here.  However I don't have a CubePro (and I would NEVER purchase another 3DS product!).  3DS is such a bunch of A$$holes to mandate this crap in the first place.  They want to control all hardware/software and try and grub money off of their unreliable and overpriced consumables.  What they don't understand is that the maker community is fundamentally different than most of the brainless sheep that run Apple products...

At least now CubePro folks can use alternate slicers...

In any case, if someone ever finds a BFB File Manipulation method to eliminate cartridge dependencies, I stand by to implement it in the RECODE function...

On Monday, October 20, 2014 12:21:48 PM UTC-5, faffer wrote:

Hi Ron unlike cubex firmware ,this firmware for cube pro is calculating the filament usage from the stepper usage directly and writing to the chip. Making fixes on the bfb files will not work. You need to decode the firmware, I think thats the only way unless you have some ideas.If you remove the chip while printing , midway or anytime , the message is to replace within 30 seconds. this is with material -1 length 0 etc. These lines are not required actually  . I think its a typical challenge - response thing the firmware is doing with the chip .

[John Bell]

Hey guys

I was wondering if you all could help me with getting kisslicer/cubeit/codeX to work. Ive attached all the files as Ive written my diatribe :)

I have an Afinia H480/UpPlus2 (or whatever its real name is,) Ive built a reprap mendal xl and I had a Makerbot 5th gen for a week (garbage garbage garbage) so I think Im ok with the whole overall process. when the Afinia prints it prints amazing (ive used the parts ive printed on an engine at test and tune track days for my race car - theyre that good) and I have so far been as upset with the CubePRO as with the MB5th gen

when I discovered this forum I couldnt wait to get in - Im excited to maybe have a chance with the CubePRO - I need the volume to start making some manifold assemblies ;)

I downloaded KISSlicer 1.5, CubeITMod/Config files, CubeITMod49, and CodeX from this thread

I found a little rasppi reprap mount on thingiverse that Ive printed with my Afinia so I know what it looks like (pi_mount.stl)

I ran the stl file through kisslicer and used the instructions/settings I found for the cubeX (changed everything over to white abs, 1 extruder, 2mm raft) and left the things as configured in the 'stock' files. I also updated the settings in the post process setting to: CubeItMod491 "<FILE>"

attached is also a pic of the object in Kisslicer (kiss.png)

all of that looks good (file pi_mount_kiss.bfb)

I took the bfb file it makes and added the following in TextPad - for giggles I added the M404 S40 code as the first line after the ini files - it does heat the box, but the screen shows heating and the bar is at 99% the whole time

^Firmware:V1.00

^Minfirmware:V1.00

^DRM:000000000000

^PrinterModel:CUBEPRO

^MaterialCodeE1:-1

^MaterialCodeE2:-1

^MaterialCodeE3:-1

^MaterialLengthE1: 0.000

^MaterialLengthE2: 0.000

^MaterialLengthE3: 0.000

M404 S40

then I ran it through cubeX; selected CubePRO, encode, and picked the file (pi_mount.cubepro)

I opened that up in cubePRO as I figured this gave me one last sanity check and it would let me upload/verify the file to the cubePRO easily - screenshot (cubepro.png) and everything looked good

I uploaded the file to the printer and hit start, the chambered warmed up but was stuck on the 'heating' page with the progress bar at 99% the whole time (I assume thats because we dont understand the M404 SXX command yet?)

right away the thing wasnt printing right. the extruder tip wasnt close enough in some spots and was too close in others, but whatever, I figured thats how it printed a bed, so I went and did the leaves/lawn for an hour - when I came back to it it seems to have finished 80% of one print then went to start another print - weird thing! 

I was wondering if anyone had tips for nozzle height/other settings for kiss and the printer? 

thanks in advance, and Im totally willing to be a guinea pig for anyone who has ideas

-jb

[Silvood]

Hello everyone!

I'm an owner of a CubeX and a Cube2. For the CubeX, I use CubeItMod, which works fine, but I haven't found any solution for the little Cube2.

I saw on the internet that using an old firmware could remove filament dependency. I found this 2.0 firmware a couple of hours ago, but I was still asking myself if they were any solutions to use another slicer...
So I decide to try decode a .cube file with the CodeX software. And it works! Cube2 files are encoded the same way as CubePro files. So now, I can start thinking making a lot of cool things with this Cube2.

Thanks!

Attach, a .cube file, encoded and decoded :)

Le mardi 7 octobre 2014 18:53:13 UTC+2, Ron Konkoma a écrit :

CodeX: CubeX companion tool - Decodes, Encodes, and HOPEFULLY Removes Filament Dependencies

Both 32-Bit and 64-Bit versions included...

Functions:
    DECODE: Take a native CUBEX/CUBEPRO file and DECODE it into an ASCII text G-Code (BFB) file.
    ENCODE: Take a *.BFB G-Code file and ENCODE it into a native CUBEX/CUBEPRO file.
    RECODE: Take a native CUBEX/CUBEPRO File, decode it, strip out filament directives in the header ("^Material..."), and then RECODE it back into a CUBEX/CUBEPRO file.

The RECODE function also leaves behind a couple of temporary BFB files for your "enjoyment".
For example, if RECODING an input file named TEST.CUBEX:
    TEST.ORIG.BFB: Decoded Original File
    TEST.CLEAN.BFB: Decoded Original File with all "^" directives (except "Firmware...") stripped out
    TEST_CLEAN.CUBEX: Recoded File without Filament Directives

Can be run as a Windowed App or Command Line Post Processor.
Command Line Syntax:  CODEX [CUBEX|CUBEPRO] [ENCODE | DECODE | RECODE] [Input File Name] [Output File Name]

The interface might be a little rough right now, but I'll clean it up as we go along...

--->  Please focus on testing the ENCODE/DECODE functions first!  (I don't have a CubePro to test)...

--->  Once we confirm everything is decoding/encoding properly, we can focus on what needs to be changed to remove filament dependencies.

--->  (You can always edit the decoded file manually, before you encode it again to send it to your printer...)

Lets confirm encode/decode are working for both printers!

[giovanni.v]

Great news !!!

Does this work for all the models of Cube ? ( Cube , Cube 2 and Cube 3 )

If you remove these lines :

^DRM:000000000000
^Cube:2
^Type:0
^Time:25
^Material: 1587.396

can you print without the cartridge inserted ?

[Silvood]

I have tried many possibilities:
if I remove the cube line, I get an error "Unable to print file" with my Cube2/Firmware2.04
if I remove the DRM line, I get an error "Print file protected" ------------------------------------------
The others lines can be removed, Type (Abs or Pla I think), material (quantity needed), Firmware (what is the purpose of this line?), and time (it doesn't show anything related to time on the screen without this line)

For the cartridge, unfortunately, the cube2 with Firmware 2.04 check if there is a cartridge inserted before choosing the print file.
Futhermore, we can't remove the cartridge during the print, an error appear: "Please insert Cartridge within 30sec"

So, I decided to downgrade firmware to the 2.00 I get yesterday.
With this firmware, the only condition to print is a cartridge to be in place, an empty cartridge for example :)
So I'm now using bulk filament with my Cube2, thanks to this firmware

Let's now talk about Kisslicer and CodeX.
I'm not very aware on how to proceed, so the only attempt I have made yet is to Slice a file with Kisslicer/Cubeitmod, then add the prefix manually and launch the printing.
It launched it. But I aborted immediately because I think there is many parameters which differs between the CubeX and the Cube2 on Kisslicer. Moreother, do I really need CubeItMod when I'm using CodeX?

Thanks for the CodeX software, but could you make an update and add the Cube2 option? (just the name which change, not .cubepro, simply .cube)

If you want me to tests more things, just ask me :)

[giovanni.v]

So, I decided to downgrade firmware to the 2.00 I get yesterday.
With this firmware, the only condition to print is a cartridge to be in place, an empty cartridge for example :)
So I'm now using bulk filament with my Cube2, thanks to this firmware

Yeahh !!!

Good job!

 

Let's now talk about Kisslicer and CodeX.
I'm not very aware on how to proceed, so the only attempt I have made yet is to Slice a file with Kisslicer/Cubeitmod, then add the prefix manually and launch the printing.
It launched it. But I aborted immediately because I think there is many parameters which differs between the CubeX and the Cube2 on Kisslicer. Moreother, do I really need CubeItMod when I'm using CodeX?

Don't use Cubeitmod, because this software makes a lot of changes into the file to have a very precise extrusion based on the Cubex capabilities, this will certainly not fit the Cube.

In the future and if needed Cubeitmod can be adapted to the Cube to improve the quality but as I don't have a Cube it will not be easy to do this for me, because it requires a lot of tests to find the parameters to put into the algorithm.

Remove the "Include comments" and try with Prefix, Select Extruder, Deselect Extruder tab if you can only with these tabs put the code required by the Cube and then code it with Codex.

Thanks for the CodeX software, but could you make an update and add the Cube2 option? (just the name which change, not .cubepro, simply .cube)

Ron is the author of this software.  

[Thomas Martin]

I have been using KISSlicer for almost a year now on BFB-3000 printers. I have a CubePro Trio now and have gotten it to receive KISSlicer files converted to .cubepro from .bfb, but it doesn't seem to be converting the feed rates from the BFB printers to the CubePro feedrates. I keep getting filament errors when printing, what have people done to solve this?

Thanks,
Thomas

[Ron Konkoma]

[Steve Martin]

Looks promising for CubePro.  I decoded an output file from their slicer just fine.  Then I created a simple stl file, sliced it with KS and fed it into your program.  CubePro attempted to read the encrypted file, but failed with some kind of 'bad format' message.  I then copied the first few lines from the previously decoded file into the generated brb file, re-encrypted, and tried to print again.  This time it was a success.  So, from first pass, it looks like your encode/decode is working.  Way to go!

Here are the lines I inserted into the brb file to make it work.  I didnt' try different iterations, so I don't know which were necessary.

^Firmware:V1.00

^Minfirmware:V1.00

^DRM:000000000000

^PrinterModel:CUBEPRO

^MaterialCodeE1:-1

^MaterialCodeE2:-1

^MaterialCodeE3:200

-Steve

[Ron Konkoma]

It appears that the DECODE and ENCODE functions are working properly.  The problem may be in determining what the minimum "header" requirements are for the CubePro.  Thats why your first attempt was rejected by the printer (invalid header contents - note encode/decode problem).  This has already been pretty well documented for the CubeX.  All you need is the "^Firmware..." line in the header to satisfy the CubeX.  Obviously, the CubePro might be different...

The other obvious question is how to eliminate proprietary filament dependencies.  (I don't have a CubePro - so I can't test this...)  However, with the CubeX, all we had to do is eliminate the lines which specified the Material Info ("^Material...").  In the end, all we did was eliminate everything in the header except for the "^Firmware..." directive and the CubeX was happy...

Please continue to test CODEX.  The following investigations would be well deserved:

1.  Slice up some models using the native CubePro Slicer.  Use CodeX to Decode those models and then manually edit them to determine what minimally needs to be done to remove filament dependencies.  Use CodeX to Encode them again before sending them to the printer.  For example: I see the ^Material..." declarations in the header, some seem to be set to "-1".  Should they all be set to "-1" to eliminate any filament checking, or should they simply be deleted...  Obviously, this needs to be tested with no cartridge installed in the bay...

2.  Once we get a better handle on what minimally needs to be included in the print file "header", then the next step would be to automate the process to take output from other slicers (KIsslicer) and make it compatible.  This is what the original CubeX CubeIt utility did for the CubeX printer.

Now that we can decode and encode CubePro files, it should be pretty easy to determine what needs to be done to eliminate filament dependencies as well as integrate 3rd party slicers!

Once all this gets quantified, I'll update the CodeX utility to do all this automatically...

[alex...@summit-tech.ca]

Good stuff! Just tested decode for the cubepro file and it worked like a charm. Going to test out encoding and printing now. So excited :)

[Ron Konkoma]

Lots of juicy goodness in those files!  ;-)

[alex...@summit-tech.ca]

I encoded the bfb produced by KISSlicer to cubepro no problem. I inserted the following in the header of the bfb file:

^Firmware:V1.00
^Minfirmware:V1.00
^DRM:000000000000
^PrinterModel:CUBEPRO

The file loads no problem in the CubePro software and the CubePro Duo started printing it with no complaints. Now I can finally escape from the crappy CubePro software and I guess this might mean that any filament can be used now. Now just need to learn how to use KISSlicer properly and figure out how to control the heater in the CubePro.

Thank you so much Ron.

[hugues]

Congratulation !!

[BFGThe]

This is amazing - thank you so much Ron! The CubePro software has been driving me crazy with it's terribly slow, seemingly illogical Gcode and horrible support generation.

I can confirm that the encoding and decoding to/from .cubepro file format does indeed work successfully. I am in the process of changing variables in CubePro to try and identify what changes in the .bfb file. The aim being to have a set of .ini files like with CubeIt to make KS a bit quicker to use, yet take advantage of the 3 nozzels and control the chamber heater.

I have attached a few files for others to look at in case it's of further use. All are done with ABS except UP Mini clip_Noz3_blackP_noRaft_noSupport.bfb, which is PLA.

I noticed that all have a section above '^InitComplete' that is always the same and the 'postfix' always ends with M107. Could M107 be the chamber heater maybe? Will proceed with tests and report back.

Anyone had any luck using Cura to create .bfb files?

[giovanni.v]

M107 on the Cubex is Fan Off.

But there are some other code that are not present on the Cubex, maybe the chamber is one of these, I'll make you a list later.

Try to remove the ^Material lines into the header and then remove the cartridges from they support as the microchip doesn't touch the contacts and try to print, this is an important test to know if you can print from bulk filament without original cartridges.

[hugues]

Hello Cubepro users,

As the cubepro file are close to be discover and kisslicer fully available for this printer, we can start to see more improvement on your printer. I'm looking for a user who want try a better hotend like a merlin hotend (0.2/0.3/.05 nozzles) or a E3DV6 (0.35mm nozzle), i can send one for free but i need feedback and pictures of your tests prints. Is someone interesting by this ?

Ron, if you want i can move my message to an other topic, i don't want to pollute your thread.

[giovanni.v]

Here is the G-code that differs from the Cubex :

M227 has G and F parameters, the Cubex only has S & P

M231 ( not present on Cubex )

M232 ( not present on Cubex )

M233 ( not present on Cubex )

M106 has a P parameter, on Cubex only M106 is used to enable the fan

G4 P2 ( maybe this one enables the heater )

M601 ( not present on Cubex )

M240 ( not present on Cubex )

M104 has P1 parameter, on Cubex only S parameter

M601 ( not present on Cubex )

M404 ( not present on Cubex )
M561 ( not present on Cubex )

G4 P1 ( maybe this one deseable the heater)

When I've time I'll test these functions on the Cubex to see it the firmware can understand them.

Le vendredi 10 octobre 2014 06:26:45 UTC+2, BFGThe a écrit :

[alex...@summit-tech.ca]

Yeah don't really see any g-code that looks like it would be to turn on/off the heater in the header and footer except for the G4. Maybe they re-purposed it?

For the RepRap the g-code for the bed and chamber is set with M140 and M141. Can always try adding the g-code M141 to the header and footer as well and see if the printer responds to it.

Also maybe the heater is activated based on the special material headers?

^MaterialCodeE1:258
^MaterialCodeE2:-1
^MaterialCodeE3:-1

I wouldn't put it past them to do something like that.


On Friday, October 10, 2014 8:13:18 AM UTC-4, faffer wrote:

I think G4 P0 to enable heater for ABS , G4 P2 enable heater for PLA and G4 P1 to disable heater. I could be wrong though

sorry guys ... 

G4

P

Dwell (no motion for P seconds)

[alex...@summit-tech.ca]

Hmm actually M404 seems more likely after comparing the PLA and ABS cubepro files and the S parameter seems to be make more sense for setting temp. Will test now.

[alex...@summit-tech.ca]

Yeah it's M404. For just ABS the init g-code is.

^Time:91
M404 S40
.
.
.
M404 S60 P1
M107
^InitComplete


If the print is just PLA then M404 is completely absent. Interestingly though if it's a mix of ABS and PLA the the header is:

^Time:166
.
.
.
M404 S0 P1
M107
^InitComplete

I guess S is the temperature and but not sure what the P1 does.

[BFGThe]

Was able to get a successful print from KS (see attached file), but found I had to move the header details to the very top of the file. Received 'Invalid file format' error when it had all the KS information first. No chamber heater values added to this one, but was just a small object so not too much of an issue. I'm still learning KS, so not even sure if there's a way to add heater control values, other than simply turning it on and setting temp in the prefix and off (temp 0) in the postfix.

I have found that you can set all 3 MaterialCodeE lines to -1 and the machine ignores what material cartridge you have loaded. Similarly (from what I can tell) if you set the MaterialLengthE values to 0.000 it can't tell how much material the file should use, so won't throw a 'Not enough material' error if you actually don't have enough material in the cartridge. However, the machine does still write the amount actually used to the cartridge chip, even if you set MaterialLengthE values to 0.000

As my main goal has been to find a better slicer than the CubePro software, these lines for material have been of less concern, but I am also interested in finding a way to use alternatives. Unfortunately as this stage, it looks like the machine is pretty well locked down to require a cartridge to be in place before it will start printing. That is by no means definitive , but from my few tests so far the machine throws a 'not enough material' or 'cartridge removed' error if you start with no cartridge or try to remove it part way through. Further to this, if you remove all Material lines and take the cartridge out, it appears to work, but then prompts you through the 'Change Cartridge' process. I have not tried putting in a non 3DS filament at this point to see if it would then proceed. More testing is required on this front, though it would be very annoying to have to do this every time you print something.

As for chamber heater, it's definitely M404. S param certainly looks to be temp, but as with alex, no idea what P is for.

As with previous machines, M106 and M107 is fans on and fans off. 

[giovanni.v]

I have found that you can set all 3 MaterialCodeE lines to -1 and the machine ignores what material cartridge you have loaded. Similarly (from what I can tell) if you set the MaterialLengthE values to 0.000 it can't tell how much material the file should use, so won't throw a 'Not enough material' error if you actually don't have enough material in the cartridge. However, the machine does still write the amount actually used to the cartridge chip, even if you set MaterialLengthE values to 0.000

 

 

 

Ok , this interesting, can you try with an empty chip if you can start printing ? 

[gianfran...@3dz.it]

Hallo, I can't use KS with Cube Pro. i Try to use Codex software but it doesn't Works.

Somebody can help me please?

[BFGThe]

@giovanni.v - I been thinking about that too, but don't have an empty cartridge to test with. I suspect that the machine firmware will check that there is material in the cartridge before beginning the print. I'm guessing that if you set MaterialLengthE to 0.000 and have > 0% material it will begin the print, but a chip with 0% will not. The problem being that no matter what you do to the build file, the machine still writes the amount used to the cartridge chip so you will always end up with chips with 0%. As such we are locked into the cartridge purchasing cycle. I guess you could pull the cartridge once the build actually starts successfully and is part way through, thereby lengthening the life of the chip. I haven't tested that just yet.

@gianfran - I'm really new to KS and found the best place to start was with the files for Cubit Mod (see back in the main thread). Loaded the printer profile and ini files as per the instructions and modified the Prefix with these lines

^Firmware:V1.00

^Minfirmware:V1.00

^DRM:000000000000

^PrinterModel:CUBEPRO

^MaterialCodeE1:-1

^MaterialCodeE2:-1

^MaterialCodeE3:-1

^MaterialLengthE1: 0.000

^MaterialLengthE2: 0.000

^MaterialLengthE3: 0.000

And then in the postfix I added

M103

M104 S0

M204 S0

M304 S0

M107

After slicing the file you then need to move those postfix lines to the very top of the file. Save and encode with CodeX. That's the quickest way to get a KS file to print on the CubePro - there's a few other variables you can change or add (like M404 for heater control) but that's all stuff we're still figuring out.

[Ron Konkoma]

If someone would please test the header modifications which need to be made for printing with generic filament, I would be glad to implement those in the "RECODE" function.

I think a suitable test would be to slightly dislodge a print cartridge or just cover the chip reader contacts with tape or paper.  We simply need to simulate that a cartridge is being used which does not have a chip installed.

Please test if setting all Material Codes to "-1" and all Material Lengths to "0.000" is sufficient to disable cartridge checking.  Perhaps just removing both those entries altogether would also be sufficient....

If someone can confirm what needs to be done, I will be happy to implement/automate that functionality...

Let me know...   Thx!

[faffer]

Hi Ron unlike cubex firmware ,this firmware for cube pro is calculating the filament usage from the stepper usage directly and writing to the chip. Making fixes on the bfb files will not work. You need to decode the firmware, I think thats the only way unless you have some ideas.If you remove the chip while printing , midway or anytime , the message is to replace within 30 seconds. this is with material -1 length 0 etc. These lines are not required actually  . I think its a typical challenge - response thing the firmware is doing with the chip .