Thanks Thanks:  9
Likes Likes:  6
Dislikes Dislikes:  0
Page 1 of 5 123 ... LastLast
Results 1 to 10 of 44
  1. #1
    Super Moderator
    Join Date
    Nov 2016
    Post Thanks / Like

    Ultimaker Cura for Cube3...

    I suppose we should make a thread for Cura related things for the Cube3 in its own place.

    Current version of Cura at the time of this post is 3.4.1.

    Interesting find: Cura has included a BFB profile!
    I already looked at the output Gcode file and it doesn't look too bad.

    However, let it be known that the Cube3 slicer is quite sophisticated.
    The per-layer routine is quite different.

    I have a feeling we are going to have to allow significant compromises if we want to use advanced features of Cura.

    Let the fun begin!

    - - - - - - - - - -

    This is not a good sign... On a Lenovo with NVidia drivers in Windows 7 you get no main menu in Cura!


    All my clicks are offset by almost 3/4 below the selection box window.

    - - - - - - - - - -

    The first piece of critical Cura data... the variables!

    Reason I am interested in these is similar variables I found in the 3DS DLL's.
    Hoping to do a cross between them.
    This is also what you can use in Cura scripts from what I can tell.

    - - - - - - - - - -

    Okay, so the link above is 35 pages of allowable Cura "variables"...

    These are the same variables used by 3DS in their BFB DLL.

    Notice that many of these load the info section of the .cube3 file... but of course, that means we should be able to properly populate these fields for the Cube3 to see.

    Now to match them up :| I filtered out the blowfish and other non-bfb tagged variables.


    - - - - - - - - - -

    First problem I ran into...
    layer heights are limited to 3 decimal places.
    I confirmed that Cura simply ignores the 4th digit.
    So our layer height of 0.1925mm has to change regardless.

    This isn't much... for 2000 layers that is an error of 1mm.
    Or 385mm tall vs 384mm

    Using the BFB printer flavor in Cura, the M108 Snn.n calls are within a reasonable range used in the .cube3 files as are the G1 ... Fnnnn.n calls.

    Cura needs a "per layer" script which can solve almost everything else.

    I just need to get up the nerve to run a Cura core in between the .cube3 headers and footers after making some basic corrections.

    - - - - - - - - - -

    Not getting any response from Ultimaker on the Windows 7/NVidia issue I am having.
    Getting further along on the little laptop... use a mouse! :|

    - - - - - - - - - -

    ...findings for an enhancement request to the Cura S/W team... forum and github;
    I requested an update to the layer thickness entry UI to be limited to only 3 decimal places.
    This request has been accepted.
    I do wish to note this only as it is relevant to the Cube3:
    Cura uses micron resolution meaning 0.001mm. In trying to mimic completely the Cube3 values directly, the 0.1975mm layer height in the .cube3 files cannot be duplicated. I also noted during my investigation that Meshmixer provides for sub-micron values only in the Z-axis. I found that notable.
    Anyway, a long discussion was bantered about and resolution was determined; the UI will limit the number of decimal places to 3 digits after the decimal point.

    - - - - - - - - - -

    I thought this thread would have to die a whimpering death...


    I finally got Cura to run on my CAD workstation.
    Turns out you have to tell NVidia that Cura is a 3D app!

    Finally have a menu in Cura and some horsepower behind the bit-cruncher.

  2. Thanks bolsoncerrado, tamer1an thanked for this post
    Likes bobskinner liked this post
  3. #2
    Regular 3D Printer
    Join Date
    Feb 2018
    Post Thanks / Like
    Kudos for pursuing Cura for Cube! I gave up trying to modify Slic3r to do proper Cube .bfb - it turned out to be above my pay grade...

    Are you working up the courage to try printing a Cura file??

    Oh, yeah... Interesting to see "set coke bottle number"!! Apparently that came from the Ekocycle firmware.
    Last edited by JohnTee; 10-29-2018 at 06:29 PM.

  4. #3
    Super Moderator
    Join Date
    Nov 2016
    Post Thanks / Like
    Ha! I'm lucky to put the horsepower behind Cura to make it usable.

    With Cura 3.5, the BFB profile is pretty close. I don't think it is a stretch to make it usable.

    What I was hoping for is to make Cura identical, but the Cura developers have decided that sub-micron information is useless.
    ...although my CAD systems, Cubify, and Meshmixer all disagree.

    Currently I am working on an alternative to standard gear meshes.
    I'm taking on the "GearDownForWhat" challenge in understanding high ratio planetary gears.
    He's using Fusion360 which has gears implemented. I'm using ProEngineer to make custom gear-teeth on the fly.
    Interesting method GearDown is using... pick a valid planetary set and match the orbit diameter for the planetary gears.
    Now scale everything to match this diameter. The smaller the difference in diameters, the larger the output ratio.

    I've long proposed a different gear profile for 3D printing. Although I fully understand the involute profile of a gear's tooth, I think 3D printing can make use of some alternate standards more fitting for this medium. I could be way off, but so far I am not seeing the disadvantages short of efficiency. The solution is a cross between belt systems and conventional spur gears. I'm hoping to show improved strength.

    Care to build a robot?

    Oh, yea, Cura... Funny thing is, I can really see some of the power in the cubify slicer. Some serious shortcoming for just dumping some models onto the platform, but when you design to the slicer, it can do some really nice things. I keep the numbers 0.9mm and 1.8mm close to my design requirements.
    I don't see spending a lot of time crafting a print file as being useful. Are you up for this kind of testing?

    - - - - - - - - - -

    Made a little progress in Cura when I tried the Spirallize mode.

    I still have a lot to learn about how to adjust a couple of critical settings.
    However, the file prep for Cube3 seems to be pretty simple so far.
    The process is highly dependent on getting settings that don't exceed Cube3 capabilities but still manage flow rates and velocities.

    The spiralize results demonstrate excessive heat and excessive extrusion.

    The results of using a highly customized BFB profile is the part below:


    This is a very thin print. I used the randomize on the seam and almost doubled the print time.
    It is also doing a while lot of "wall bonding" where it does a lot of dots between the walls.
    This left a lot of artifacts.


    I chose this print to see what we can expect on something challenging.

    I don't know if Cura does this or if this is unique to 3DS.
    However, this function is critical in making 3DS prints strong.
    At the base, there is a high angle (gentle slope) at the base.
    3DS will do a fill along the edge of the current layer so that a subsequent layer has a solid foundation to print on.
    The closest I found in Cura was to "add additional wall(s)" but that just made a mess in this configurations by printing in air.

    Anyone know what I am talking about and how to solve it with Cura?

    Okay, bottom line:

    The BFB output from Cura has a reliable output file. The only intermediate calls are start/stop extruder commands (M101/M103/M108).
    This activates the F/W locked destring built into the Cube3 Initialization routine (M227/M228).
    What this means for splicing the files is that the initialization routine will set several settings are only set once.
    Temperature is only set once...
    Retraction parameters are only set once...

    Therefore, the entire part BFB section must manage proper filament feed velocity and head velocity.
    These are tricky as the slicer is completely different. I'll need to see what 3DS limited these values to.
    I suspect an 89.5 value for M108 will cause problems.

  5. #4
    Regular 3D Printer
    Join Date
    Feb 2018
    Post Thanks / Like
    So you are actually printing Cura files?


    Can you share how you set Cura up to do this, and what you have to do between Cura and cubeencoder?

  6. Thanks buddybu thanked for this post
    Likes buddybu liked this post
  7. #5
    Super Moderator
    Join Date
    Nov 2016
    Post Thanks / Like
    Just getting there but it is pretty straight forward. The sleuthing is the hard part.

    If you've played with Cura, you know well that a profile is a illusive as a memorable fragrance.
    After dozens of failures you get a good one!... but wait, what was it really... um... cr.p!
    I have the attention of a fly when it comes to applying the scientific method.
    If I can't go at it with a sledge, without killing me, I may do a reset and take a more disciplined approach.
    That's pretty much how we got to this point

    I was using v3.6. Only recently learned there is an actual menu on the top line so this is worth stating to Windows 7 users that use NVidia!
    = CURA NEEDS TO BE POINTED TO NVIDIA DRIVERS IN THE NVIDIA CONTROL PANEL/PROGRAM SETTINGS - choose the H/D NVIDIA processor; the intel graphics come through by default and they negate to show the top line of the menu... along with some other nasties. This is a Lenovo, but the problem was there with Dell too.
    If you see a file menu in the upper left hand corner, ignore this part of the post; but if like me you put Cura away for it absolutely horrendous user interface, look again... (imagine running Cura without that menu!)

    Okay, copy the BFB Printer profile. That is your starting point. Same with copying a material because you'll probably amass a library.

    And I took a quick look at the "Normal" profile and I copied that for Cube3_PLA_profile. It has a few good presets with calculations. One of the Cube3 XML files explains how they figure the extrusion. That will come in handy I'm sure.
    I made the layer thickness 0.2 and used the search to find "layer" to get the staring layer height... 0.25 is right but you may need to get closer... with caveats. I was successful with the above print using 0.15 but you see how thin it is. That was my brute force print. Now I'm digging a little deeper.

    One thing that eludes me in Cura is the easy way to make sure all the tweaks are saved. I finally found the button to update the profile, but that is it.

    Sleuthing; You're gonna need to recognize a good gcode file from a bad one. I'm looking at the M108 values which can overdrive your filament motor and the basic velocities of the Fnnnn.n values in the G1 calls. Also become cognizant of moves after a M103 issue. These are just moves that I have not yet explained. I'm working on getting the acrobatics of Cura to go away and come up with a very basic "Cubify" mimic. From there I play.

    Decode and open up the print files from the CubePrint app. Find those #vector calls. They are equivalent to the memos thatr Cura spits out defining inner wall, outer wall, hatch... etc. You are looking for these values to be similar in the Cura gcode file. Learn the max value. Right now I am holding M108 under 40. Velocities under 40mm/sec but have yet to find what allows non-printing moves to reach F8000.0, which I am also considering a velocity limit.

    Remember that slow is good if you have nozzle control. If you can make bridges without droops or breaks, you're 80% there. But be careful at what you throw at your printer! This is your only warning!

    Pre, just past the Init all the way to where printing starts in earnest; Printers>machine settings>Start G-code
    ^MaterialLengthE1: 7910.877
    ^MaterialLengthE2: 0.000
    ^MaterialLengthE3: 0.000
    ^ModelHeight: 126.857
    ^LayerCount: 659
    M227 P300 S300 G800 F800
    M228 P0 S300
    M231 P0 S0
    M232 P5000 S5000
    M233 P1000
    M106 P100
    G4 P60
    M601 P3 S60 F5
    M240 X450
    M240 Y400
    M228 P0 S1
    M227 P1 S1 G1000 F1000
    M601 P8 S60 F5
    M240 S450
    M204 S155 P1
    M104 S155 P1
    G1 X-100.500 Y0.000 Z5.0575 F7000.0
    M104 S225
    G4 P15
    M551 P850 S50
    M104 S210 P1
    M601 P2 S60 F5
    M240 X400
    M240 Y450
    #Vector T22
    M104 S210 P1
    M228 P0 S300
    M227 P300 S300 G800 F800

    You might see I did a little tweaking in there. Retraction settings are very useful tweak handles throughout the print. It becomes a universal setting and for every M103, it will do a destring z-drop through F/W. Cura doesn't have to reinforce the concept. You can tweak it here with 4 parameters rather than the generic G-code's 2 parameters.

    Post; End G-code

    M106 P100
    M240 X450
    M240 Y400
    M228 P0 S1
    M227 P1 S1 G1000 F1000
    M601 P8 S60 F5
    M240 S450
    M204 S235 P1
    M104 S145 P1
    M108 S22.5
    M561 P100 S700
    G4 P0
    G1 X-100.500 Y0.000 Z126.9150 F7000.0
    M104 S210 P1
    M561 P10 S700
    G4 P1
    M204 S245
    G1 X105.500 Y0.000 Z126.9150 F7000.0
    M204 S260
    M552 P500 S25
    G4 P5
    G1 X100.500 Y0.000 Z126.9150 F7000.0
    G1 X87.000 Y0.000 Z126.9150 F7000.0
    G1 X105.500 Y0.000 Z126.9150 F7000.0
    G1 X87.000 Y0.000 Z126.9150 F7000.0
    M204 S260 P1
    M601 P2 S60 F5
    M240 X400
    M240 Y450
    M106 P100
    M104 S0
    M204 S0

    (careful about copying and pasting from posts... I've seen values from from negative to not-negative)

    This was a brute dump attempt. I removed the default entry in both categories.
    A lot of tweaking can be added to this but it is the safe route.

    Now when Cura outputs the print file, .gcode, it will add a few lines in the header - delete. These are temperature calls. Cura will never deal with the dual heated heater block properly. This is a shared heater system that is managed by the 3D Systems' slicer specifically for Cube3. I don't know of any other BFB printer that does that. And make no mistake, we have a BFB printer! ...just much more mature.

    There is another section that the output file adds just before printing. It is part of a M227 declaration which should also be deleted promptly.
    The end of the file nothing cares about but the Cura settings are stored there! That is the -only- breadcrumb you get to know what you did.
    The encoder accepts the semicolon as a comment. Haven't even tried reverse decode to see if they remain yet. But it works!
    The edit process with these commands pre-loaded makes the edit pretty darn fast. That I like! And it is also fairly intuitive.
    And best of all, you can tweak your 3DS settings right here in Cura by managing the initialization once we catalog the entire gambit of their commands.

    ...did you suck all that up?
    Vase mode... Spiralize! This has even better opportunity for quick results with Cura. Some heat management needs to be considered. You might start with a good profile but copy it for Spiralize because you will want to slow it down.

    You will get a base by default. Haven't found a way to turn it off, but obviously it can removed and replaced. It will follow whatever rule you have set up in the profile.
    To activate the Spiralize mode, in the parameter search, type "spi" and one or two entries will come up. There is a sub-option. I'm sure there are internal rules in Cura but you might go to MakerMuse to get some insight about how to design for Spiralize. Anyway, this creates a continuous print the rest of the way up. There will be a limited set of values for the M108 calls that can easily be edited once you get a conversion rate figured out.

    The retract characteristics are on you in the init. No other M227's are assigned. If you get blobby starts, you get to play with the 4 number. They have some bazaar behaviors but fun to watch. Nothing dangerous to the machine. Maybe messy.

    Let me know what I forgot.

  8. #6
    Regular 3D Printer
    Join Date
    Feb 2018
    Post Thanks / Like
    I used Cura 3.6 to slice my little test cubelet, cobbled up the bfb file, encoded and printed.

    It came out not-too-bad. Not as nice as Cube Print did it, but almost passable.

    All four sides had week adhesion between the first and second layers along the outer edge. The top surface is a bit coarser. There is an interesting 'stitching' pattern between the top infill and walls. The cooling tower looks pretty much identical to the Cube Print version.

    So far, for straight printing (no overhangs, no supports, etc) with PLA, I don't see any advantage to Cura over CubePrint. That said, there are still a lot of features to be investigated!

    P1080345.jpg P1080347.jpg

  9. Likes garufa liked this post
  10. #7
    Super Moderator
    Join Date
    Nov 2016
    Post Thanks / Like
    Now that is excellent work, John!

    ...on the contrary, I thing some of the options in Cura would be excellent if we get a good foothold on some settings.
    Check out the experimental settings on "fussy skin" for instance (thanks Maker's Muse).

    We loose out on some features but we can edit those. It is that precise balance between feed and speed that must be maintained.
    I'm going to guess you are under-extruding still.

    Can you post the limits of the G1 Fnnn values and the limit of M108, and M227 you're using? Just a ballpark of the higher calls.

  11. #8
    Regular 3D Printer
    Join Date
    Feb 2018
    Post Thanks / Like
    I agree completely that Cura is worth pursuing, not the least for the security of having an alternate method to generate print files. Thank you for getting us this far with Cura!

    Wow. Looking at the print file to suss out the values you asked about -- I noticed that the first layer Z values are all 0.5 !! Second layer is 0.7, and so on. Yikes, no wonder the adhesion is spotty at the bottom. Now I have to go look at my printer and material settings in Cura.

    Here's a comparison of the G1 "F" (move speed) values and M108 "S" (extrude rate) values from Cura and Cubeprint for the same .stl file.

    Cura CubePrint
    G1 F value M108 value Ratio * G1 F value M108 value Ratio *
    1198.4 3.3 363 1200.0 29.0 41
    1198.6 3.4 353 1800.0 22.5 80
    1199.3 7.6 158 2000.0 32.0 63
    1199.8 24.9 48 2000.0 37.0 54
    1199.8 10 120 2750.0 40.0 69
    1199.8 5 240 2750.0 32.0 86
    1200 4.6 261 2750.0 40.0 69
    1200.2 12.5 96 4500.0 39.0 115
    1200.3 3 400 5000.0 39.0 128
    1200.9 5 240
    1201 3.1 387
    1201.3 3 400
    1201.7 3.1 388
    1799.6 15 120
    2399.5 20 120
    * Ratio = Move speed / Extrude rate = G1 F value / M108 S value

    The rows are not in print file (aka execution) order! They are sorted by the first column, G1 "F" value. There is no indication as to the number of time each value appears in the bfb file.

    The CubePrint file had 8,035 lines of code and the Cura file had 13,233 lines.
    Cura does many many more retacts than CubePrint. I was afraid my extruder cog would wear out!

    Is that the kind of limits you were looking for?
    Last edited by JohnTee; 02-01-2019 at 02:27 AM.

  12. #9
    Super Moderator
    Join Date
    Nov 2016
    Post Thanks / Like
    ... there is a 1st layer height settings. Real simple and it works.

    I'm pretty sure both are stepper counts per cycle (like RPM - Count per second).
    Internally that would translate to length per minute or something unimportant.
    What is important for us is to understand the way Cura applies those 4-someodd variables.

    Notice the great disparity in Cura's M108 calls over Cubify.

    Just so we remain on the same page, you are doing Ekocycle references, right?

    That may be a better place to start anyway. Much more sensible slicer!

    - - - - - - - - - -

    So the Vector numbers in the Cube3 files. We want to closely mimic the #Vector T22 calls... the outline traces, and the top and bottom fill #Vectors (don't have the T# on hand). However, we could care less about the fill because we want Cura's fill options. And we do care about the #Vector that manages series of dots. I saw that Cura loves generating dots! But Ekocycle prints too go through "dot-fills". And these too have a specific parameter of their own.

    Bottom line, we get to tickle each feed and speed parameter in the menu to see if we can coax understanding from what we see changing.

    Logic on feed and speed (need a machinist!) is that greater speed requires more feed.

    So feed is rotations on the filament driver via the stepper. Say "40" (40 what!?!) I can only assume for the time being, by default it is 40 steps per second. Correct me if I'm wrong but cheap steppers are 200 steps per revolution so the rate of filament feed is 1/5 rotations per second or 12 rotations per minute.

    Here is that critical conversion data that 3DS provided us in one of the libraries:

    Below layer distances are calculated with following code from bfblib.cpp:
    bte(): dx = (x1 - x0) dy = (y1 - y0)
    mag = sqrt(dx * dx + dy * dy)
    float Dist = (mag / drawSpeed) * (extruderSpeed /10.0f) * 25.397f
    25.397f = filament pulled in per extruder stepper revolution
    Layer0 is sum of all other layers --> %p eE pP
    This one is pretty darn clear... the rate is here mm per revolution MM/200 is the internal "filament used" clock.
    And we know that 3DS was using inches as their reference for filament advancement as 25.397 is just a hair oven an inch.

    But look at these other calcs....
    The values are quite familiar. The bte() is the distance traveled in X and Y (delta x and y)
    Then mag (magnitude) is the square root of the sum of two squares... sounds familiar, right? Bottom line, we now have a distance traveled from A to B (from G1 to next G1)... tiny hops! Tiny numbers!
    the Float... this gets interesting.... and I could be way off so help here; mag already defined, distance traveled divided by "drawspeed" (F-values or derivative).
    mag/drawspeed is a time element (from here to there how fast) multiplied by ...
    Extruder speed / 10.0f... (pondering here).
    I'm gonna take the "f" to simply mean fixed value in code...
    So easy, they are taking our extruder speed; M108 or derivative, and dividing it by a fixed value of 10. This is where they make platform specific settings. We also have to consider that this may not be fully updated considering the very poor estimates that the Cubify spits out for print estimates. But its a start!
    Okay, so we take out 40 and divide by 10 and come up with 4.
    Now we multiply time by extrusion velocity... 40 * 4 = 160 * 25.397 = 4063.52 (?) Now, what the heck is float distance! Maybe the spaghetti infill is considered a float operation and they are just throwing a velocity at an active extruder?
    Crunch the number with 25.397 and you get the tiny dot of plastic that would have just pooped out the nozzle (if you could manage the ooze).

    Okay, that made my head hurt. Someone please check me.

    Checking the filament driver against the numbers provided, they appear close to accurate.
    It is good that they defined the filament advancement based on pulled in filament not pushed out.
    That makes sense that we should be measuring the take-up, not the distorted remnant.

    - - - - - - - - - -

    And for next time someone asks...

    25.397mm per rotation means the effective drive diameter is 25.397/pi. That comes out to about 8.0841mm diameter.

    It also has 24 teeth.
    Last edited by TommyDee; 02-01-2019 at 05:54 AM.

  13. #10
    Regular 3D Printer
    Join Date
    Feb 2018
    Post Thanks / Like
    Another way to look at it?

    From a chart by MegaloDon
    ( ),

    the M108 "S" value represents RPM*10.

    Then M108 S40 may mean
    40/10 = 4 RPM * 25.397 mm/rev = ~100 mm/minute = ~ 1.67 mm/sec ??
    Does that seem realistic? Seems kind of low, to me.
    I've not tried physically measuring the actual extrusion rate. Have you?

    I see you can tinker with the extrusion rate (ie, M108 S value) by modifying the "Flow" and "Initial Layer Flow" % values in the Material section of "Print Setup / Custom" of the Material parameters (at menu: Settings / Extruder 1 / Generic / PLA -- on my screen .

    So Many Parameters!!!



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts