-
Well CubePro v2.02 still does not decode properly. I get some real output and some odd output...
Code:
^JLP0TUWgSoNrP84mJ2.8qeY
^PrinterModel:CUBEPRO
^Firmware:V2.00
^Minfirmware:V2.0
^ForceMinfirmware:V1.14B
^DRM:000000000000
^ConfigAndConfiguration:No-
^MaterialCodeE1:202
^MaterialCodeE2:-1
^MaterialCodeE3:-1
^MaterialLengthE1:10561.2
^MaterialLengthE2:0.0
^MaterialLengthE3:0.0
^ExtruderTypeE1:0
^ExtruderTypeE2:0
^ExtruderTypeE3:0
^ModelHeight:64.00
^LayerCount:320
^LayerHeight:0.2000
^Supports:-1
^Sidewalks:202
^Density:Strong
^Pattern:Cross
^Time: 97
G50
?;?j????????E????i??????????#u??Q?l??t?bu#??R?&?e?Rm??
?LLh??t?]U?%?|?V??g?????
g?q-?!u?zT??#??.????cH?T?? ?nM[*"???? U8?????%?U??u?G
The rest of the file looks like the end, so they did something else or encrypted the remainder of the file.... with something else.
-
Yes they did the bums! But not their .xml config files. No one has dug into that from what I've found. I've tested all the previous versions of CubePro only to find v1.87 to be the latest that is supported by previous decoders.
-
It almost looks like a simple cipher, since there are some patterns in decoded data.
- - - - - - - - - -
CCubeArchive3DB
- Get3DBArchive
- SetInputXML
- Request3DBInfoBuffer
- Request3DBInfoBufferSize
- ReadCube3DBFile
- Create3DBArchive
- Destroy3DBArchive
Not seeing anything obvious in the decoder yet...
-
'Simple he says...' :rolleyes:
- - - - - - - - - -
Let me see if I am understanding the process the editor is using when using the command line;
The editor is dependent on the .cubescr file to match the .cube3 file in entries.
Somehow the .cubescr file is an index file tied to the .cube3 file where every entry has indexes tied to them.
If index entries are missing or extra in the .cubescr file, the command line will fail.
Is this a proper way of thinking the file-set related to the cube3editor.exe?
-
The CUBESCR doesn/t necessarily need to match the CUBE3 file.
If you specify that you want to replace a temperature of 250 with 235 and your current CUBE3 file does not contain an entry for 250, then nothing happens. If this is causing the command line usage to fail, then that is a bug.
I think what we need is maybe a better way to describe the changes we want to see in the CUBE file based upon the script. I am thinking possibly adding a range possibility?
Code:
modify temperature left range 250:265 by percentage 25
This would take any temperature between 250 and 265, inclusively, and decrease them by 25%
The same mechanism could be used for retractions and pressure as well.
The other thing we could do would be to add an if statement capability:
Code:
if left material is PLA then
modify temperature left range 250:265 by percentage 25
modify retraction range 375:400 by percentage 50
modify pressure 800 by replace 400
end if
The if statement may be a little more difficult to implement, but I could try.
-
Understood. I am seeing errors but wasn't sure why. I will continue testing with this premise.
- - - - - - - - - -
I had considered some alternative means to present the data.
What I see as helpful at the moment, and may require the least effort, is to read in the .cubescr file into an active cube3editor session.
-
Can you talk more about this? I am working on an update to generate, view/edit the script. I have the automatic generation, but I haven't started the editor portion.
-
I like the cube3editor.exe interface as a "catch-all" confirmation prior to pulling the trigger on file creation.
It allows opening a .cube3 file and extracts the unique data we are interested in.
What I am proposing is that you can then read in a .cubescr file to match the "from" data of the read file and replacing the "to" data from the file in the appropriate fields.
-
I think I understand. What you want me to do is to read in the script, and populate the various temperature, extrusion and pressure fields with the data that matches the existing fields. Interesting idea. Let me see if I can accomplish that. I am still working on my code signing certificate.
-
