is it possible that the extruder values are times?
Printable View
is it possible that the extruder values are times?
Mornin' Buddy.
The time element is distance per second. That is what I am equating with velocity. I need to do some profiling to understand these better. I did play with this once and I slowed the resumption response to super slow. I need to make a .cube3 file that starts quicker than the normal init routine.
Yesterday I pruned the post processing to only 4 lines. Apparently that is all we need for a single extruder. Turn off extruding, the extruders, and the fans. And internally it still moves the plate forward while it slowly descends to the bottom.
oh, and the reverse hold-off ; yea, that one always follows one of the other two in M227. M228 cancels M227. More experiments :)
Sorry, not enough coffee. Or maybe too much. :)
Are you coming up with some "algorithmic" changes that could be made to every cube3 file, such as the update you made to simplify the shut down process?
Also, any suggestions for printing with PETG? The PETG that I have has a temperature range of 220-250. I tried printing as ABS, but it gets too hot and tends to over-extrude. I tried to start with an EKO file, convert it to Cube3, but forgot to change the version/model to CUBE3 values, so it failed (the file I am trying to print is really big and takes like 17 hours)...
One thing I found odd playing with the circlip...
I was trying to write my own path for the circlip including pauses and such.
Something strange occurred...
I would move to a position under M103 (extruders off) and then move to my actual location to start still under M103.
Then issue an M101 for extruder 1 enable...
And I start making G1 moves.
Turns out that the second move after the M103 was issued still drew a trace!
Now mind you, I am not using an M108 (filament drive speed) right before the M101 as the Cubify slicer did but this behavior got me curious.
Turns out the 70 micron prints worked wonders all on its own with no modifications. Running the new C-Clips now and they are holding up well.
I'm waiting for someone to do a pull test ;)
- - - - - - - - - -
Coffee helps indeed. I am just beginning with optimizing single extruder housekeeping.Quote:
Originally Posted by buddybu
However, I do need to thank you once again for your diligent efforts.
While I was making the circlips, I would just do a wholesale replace of the core gcode and the editor program put it all back together for WiFi submission.
That is just so cool Dude! That is a feat I doubt anyone ever expected to be revived with cube3 mods.
I haven't even got to testing the the command line yet. But yes, there should be a simple M227/M228 corrections for some PLA files. What I need to test is the generic script version where extra values are included and other values are removed. Basically, a script would only have M227 and m228 updates without anything else. And it covers a series that would normally be found but may not be present. That is the reason I am back to scrutinizing the M227 and M228 commands.
Another is the Ekocycle to Cube3. The Ekocycle slicer works way too well for 3rd party ABS to ignore. It only needs a few fields changed to function. I should also be able to determine if the support and sidewalk material calls are of any real significance to the app. I doubt the printer cares as this is only information at the point of submission. Did you ever get the support and sidewalk material call implemented?
- - - - - - - - - -
...oh, and not to leave out the 3 Ekocycle users <tongue in cheek>, a few standard conversions to Ekocycle would be nice. Say you want to run PLA in your Ekocycle... That needs characterization. All the tools you have today should cover that in the same way.
Oops, the Support and Sidewalk implementations fell off the plate. Let me take a look tonight about implementing. I did find that support and sidewalk can only be assigned to one cartridge, but they can be assigned to different sides. So:
Sidewalk Left, Support Left
Sidewalk Right, Support Right
Sidewalk Left, Support Right
Sidewalk Right, Support Left
I believe that is correct, but I need to verify.
Correct. It may make no difference. It could just be a 'fit-n-finish' detail. Let me vet this to confirm.
- - - - - - - - - -
I hit a bug in the conversion from Eko to Cube3. The material didn't stick.
Test:
create an Ekocycle print...
open it in the editor.
[change f/w to V1.14B and model to CUBE3... that is working fine - can we get drop down selections here?
Change the materials to ABS and Grey.
Take a look at the BFB - material updates did not happened but the f/w and model did.
Same gets filed when saved. Both entries for material remained Ekocycle (303)
Quick fix, edit material in BFB.
As to support and sidewalk material call - my other neglected charge...
If the support/sidewalk material is not changed from Eko to Cube3, CubePrint v4.03 just reports it thus under info.
When sent to the printer, the printer ignores it after you tell it the material color is wrong.
I didn't test it if the model material callout -did- match the chip though.
I'd chalk up sidewalk and support color updates to fit and finish. This could be a headache to deal with in memory if one or the other flipped sides, if that makes sense.
- - - - - - - - - -
...now a new nagging question for the world - would Cube3 run an Eko print if an Eko cart were installed?
Basically a non-selectable option but who knows if just changing model is enough.
Ha, and I know I can answer that for myself but it is a curious question, don't you think?
Definitely have to try this now. I can make an Eko cart and see if it complains about material then!
- - - - - - - - - -
I'll be darned! Sure enough... change the cartridge to EKO White and the touch screen says PLA and some yucky blue color. However, CubePrint reported it as white EKO.
I made a new file to match the chip and only changed the model to CUBE3 and sent it via the app. The app only confirms the connected printer (material incompatibilities are managed after upload). The fact that the app didn't blow up was probably the biggest test. No fuss whatsoever when the printer got it. Had to cancel but will let it run through tomorrow.
Now I can mark my PETG carts with EKO colors! As well as my 3rd party ABS. I say this is an easter egg! We just converted Cube3 to being Ekocycle compatible!
- - - - - - - - - -
Scratch that! With the EKO cart, the print never goes past heating so something is tripping up the next operation. it was a good thought :)
- - - - - - - - - -
I really should hire myself out as a beta tester :p
So it is the "Gray" entry in ABS that is ignored and other materials update as expected.
I suspect the Gray choice is only for CubePro and therefore ignores putting a value in the BFB.
So the problem is more operator error but it did catch me off guard.
Nice Work BuddyBu! I am just tickled every time I need to do a quick tweak on a file.
Oh, and that MOD extension is working perfectly for me. I now keep it there for a reminder that these are revised files.
That was a good try. I know if you put an ABS or PLA cart onto the Ekocycle, you get a similar problem. In fact, I wonder if you can turn your Cube3 into an Ekocycle, since I know that an Ekocycle can be turned into a Cube3....
WiFi connection -- I have a list of commands that are used to communicate between Cube Print and the Cube3 printer. I need to do some cleanup, but being able to send a file via wifi to the printer should be straight forward. there is no security or handshake, just a command with a payload, a response with the TCP port to use, then start streaming the file to the TCP port. When it is done, you'll get a packet from the printer with status. (Its all a bit more complicated than this, but, it seems pretty straight forward).. I am going to start playing with commands today and see what might be supported.
- - - - - - - - - -
And I will take a look at the "Gray" as well. For the drop downs, what do you think:
Versions : V1.87(CubePro), V1.05(EKOCYCLE/OLDER CUBE3), V1.14B (CUBE3)
Models: CUBEPRO, CUBE3, EKOCYCLE
I was going to add checkboxes for supports and sidewalks for each Extruder and to allow setting as I described\
Sidewalk Left, Support Left
Sidewalk Right, Support Right
Sidewalk Mid, Support Mid
Sidewalk Left, Support Right or Mid
Sidewalk Right, Support Left or Mid
Sidewalk Mid, Support Left or Right
Support Left, Sidewalk Right or Mid
Support Right, Sidewalk Left or Mid
Support Mid, Sidewalk Left or Right
Of course, if an extruder is empty, then Support/Sidewalk for that extruder will be disabled.
Sweet. That's a lot of exploration. Did you bring enough water? ;p
The printer continue to update status of temperature and progress back to the app. Maybe something like a status window taking up minimal space can be parked in the corner of a screen somewhere if you want to capture the replies. No more glue reminder prompt? +5!
I am not fully up on how Ekocycle becomes a Cube3 but it has to affect one of the 2 BIN files on the SD I'm sure (long term memory glitch).
But yes, you should be able to go the other way by the same method. But ask yourself... why would you?
The limited choices for Ekocycle is prohibitive. However, if you are gonna run 3rd party ABS exclusively at 200 microns, yea, I could see it.
I want an Ekocycle for the red lights :o
- - - - - - - - - -
Don't worry about the mids. CubePro has its own rules about which cartridge can fit where. CubePro is very easy to update since there are no bias temps. ...and even more important, you will be replacing the entire init routing anyway.Quote:
Originally Posted by buddybu
Therefore, yes, left and right should comprise of the matrix.
'if two carts' (model = L or R)
Sidewalk L support L
Sidewalk L support R
Sidewalk R support L
Sidewalk R support R
'if one cart'
model, sidewalk, and support are the same, if present.
The choice list looks great. Can you inherently also overwrite the f/w version values in the UI (not that I know why you would)?
As for overwriting firmware version, yes, I could allow for that. Would you want that value saved for future use, so that the next time you opened a file, the value would still be there?
No memory on the field since it comes from the opened file... and no reason to manage a database of user added choices. That may become messy.
As to CubePro routine...
That one basically takes the header from a v1.87 file down to the 1st "# Vector" call. And add a "part fan on" requirements (M106 P100).
The finish of the print removed everything after the last timestamp and replaces it with a few lines.
For converted files, all the non-used extruders are removed except the final M(1,2,3)04 S0.
I would consider this a separate editor... drag and drop the valid cube3 file onto the app and it spits out the PROMOD output ready to print.
Give it a generic material number and use the file's choice in L vs. R extruders. Trio owners can use the existing editor to add E3 to print file.
I'll have to record the process to make it easier to follow.
- - - - - - - - - -
This image is worth a few words...
Attachment 3363
The process is to load the master STL...
Generate an Ekocycle print and export.
Open the exported file in the BB-editor (short for buddybu's editor of course)
Modify the Model and the Material.
Save the file.
Double click the new MOD file to bring it into CubePrint.
I now have a master and a modified file for safe keeping managed by CubePrint.
How sweet is that!
- - - - - - - - - -
Darn... forgot the elephant in the room for algo's - the pressure modifier [pg3]; "apply global percentage to all". It may be nice to see the "was" in the pressure settings. Something similar to temperate where you have the mod field and an apply except that the "[global percentage: ][ xxx.x][%]" is a dialog outside the matrix of values. you would populate via [calculate] and [update] if the global percentage field has a value other than the default 100%.
That is what I am finding myself doing with a lot of entries. The Cube3 prints are really nice on CubePro. Basically the CubePro slicer just isn't as robust for smaller prints. But the systems are close enough to the same development levels that a global tweak is right for conversion.
CubePro headers would come in combinations of how the extruders are used. Basically whatever it generates for each setting. Sidewalks and supports can be turned off so they don't populate material codes. In the case of .cube3 imports, extruders would be limited to E1 and E2.
I'd also say put your logo on the image screen instead of whatever generic image actually gets captured. The graphics on CubePro are horrendous, and I'm being generous.
I do know that Cube3 images block will not open in CubePro 2.02 so they may have a resolution conflict. This is one thing they really cleaned up in Cube3!
...And for Cube3, pressure percentage updates can thicken up or thin down prints! Didn't think though that yet. Not something you do with long bridges, but certainly an increase of pressure would close up some wall gaps, for instance.
- - - - - - - - - -
And now for an off the wall idea; Object replication within the BFB... basically shuffling every layer with the master pattern for that layer. Manage a retraction between copies... etc.
This came to me as today I made the best print -ever- on a Cube3. It was small enough that the velocity was much slower; I used a 'cooling tower' [prime tower] around the object; and this was with PETG running a modified Ekosliced print. There are no seam marks and no internal supports (clear PETG). My odds of getting this type of perfect print from a Cube slicer is astronomical. But it is one of those files that lends itself to replication. The slicer's behavior with regard to replication is not in the least considered copy-exact in slicer performance or settings. More parts on the build plate will mean longer layer times which warrants higher velocities; which equate to less quality. I'm pretty sure this was running at a 10mm/sec rate if that.
A little out of the box but hey, I'm thinking you like challenges. This might at least tease you some.
Hey, you are right, I like challenges. Those are both very interesting ideas. Let me start pondering them. But at this point I see the features you'd like:
- Ability to enable disable sidewalks and supports. (Are rafts and sidewalks the same or is this a holdover field for compatibility?)
- Ability to globally apply a pressure modifier, but don't apply it immediately.
- I assume that this will include a Cube script option, like MODIFY PRESSURE ALL BY PERCENTAGE -50
- Add a calculated pressure modifier to the pressure tab that will show what the resulting pressure will be that will only be applied if update is selected.
- Update the image in the file with the CubeEdit Icon.
Did I miss anything?
... pretty much. Clarification; 1. does not need to be dealt with. This is a CubePro thing where having templates with these turned off will simplify the user process. This is strictly for converting Cube3 to CubePro. If you are processing a CubePro file, then all the normal rules apply. So rather than the app doing anything with the enabling or disabling the sidewalk/supports, there is simply a library choice of generic headers that have these already disabled [-1] and extra entries removed. And in this instance of .cube3 to .cubepro, since the image is invalid anyway, there is a nice place to put your logo in place.
Script options are always useful. And yes on 2, 3. Same means you are using in temperature page and move and limit the calculation type to global percentage.
BTW, the CubePro conversion of that 'perfect print' came out perfect on CubePro too. I used common CubePro retractions [250, 250, 300, 700] and 80% on all pressure settings. Since it was a PETG print going to ABS, I changed temps to 260 where appropriate and manually removed the extra extruder calls in the BFB. I spliced in a simple header and footer generated by CubePro v1.87 specifically to match the extruder setup.
I printed the various portions of this model in PETG. I started with an STL set of files and converted then to CUBE3 with the cube print application using an offline Ekocycle printer. I then opened each one in Cube3Editor and modified the version and printer to match the Cube3 settings. Then I changed the material type from EKO to ABS and set the color to Blue. After that I generated the Cube3 files, put each of them on a USB drive and printed them on the Cube3. This is not without problems and the print could be cleaner, but after nearly 20 hours of printing, I am fine with the results. Here it is.
https://photos.app.goo.gl/6Ji77wwYgEq2m4Eg7
Are you using sneakernet by choice? But yes, the process is what I use. Works great for 3rd party ABS and PETG.
Sneakernet by choice? Yes. I suppose, tbh, I haven't tried loading the modified Cube3 file back into cube print and attempting a print to the selected printer. I should try that. It would get rid of the need for sneakernet.
Attachment 3370
The attached didn't work from my phone, so here it is. :)
My v20 does not require sneakernet... see image
That is one rad castle!
Re: moved thread. Artifacts...
Well, let me show you.
Attachment 3371
Those should be indents, not outdents... :)
And we should move this to the Cube3Editor thread -- it is more attuned that channel as I did edit this file with it. :)
So, moving the outdent thread to here. As you can see above with the default retraction settings, the castle looks pretty good. I was hoping to get a smoother look with changing the retraction settings, but instead, the brick indents look like this:
Attachment 3372
Those vertical lines should be indented... those are the blobs.
Ha... how'd that happen :p
So those features are not how they normally would behave. One thing about the Cubify slicer is that it just sets a pressure and goes, mostly maintaining a smooth skin.
Can you post the print file? Need to look at the sliced version.
Oh, and which filament?
Assuming one nozzle.
Sure, here is a link to the file.
I am using one nozzle. It is PETG, specifically the same filament I used for the other parts of the castle. This was to be the "shell" for the castle stairs to keep the dice from falling out. This is actually a dice roller for DnD. :)
I have been running this at ABS temperatures, but I noticed that as I was watching the print, the nozzle temp was only getting to 240C, when the file says it should be 250C. Is that normal? I don't usually pay attention to that.
I am wondering if part of the difference is that I had Cube Print send the file over wifi, but no, when I did that that before it was directly sending the CUBE3 file as stored on disk -- I captured enough packets to prove that. But maybe there is some massaging of the file when read from the USB drive by the onboard firmware when it is "processing" the file...
Hmmm...
I was going to start a reprint with the original extrusion rates to see if the same issue occurred....
- - - - - - - - - -
Unfortunately, it won't let me attach the file, it is way too big, even zipped, it was like 8 MB.
Got the file. The reason you are having trouble is that the "V" nearly dips into the inner wall trace.
You also have an overcrowding condition in the center. You must be running a wall thickness ~1.8mm.
Try a wall thickness of 2.0 or more and provide 0.9mm minimum wall at the "V" notches.
This will give the print some more room to "expand".
0.9 and 1.8mm seem to be the magic numbers for minimum wall thickness. It crowds the walls slightly over 'normal' [0.5mm].
1.8mm assures 4 walls [total] with crowding in the center. With that many starts and stops to fill each 'apron', you get a lot of 'spillage'.
I run the EKOCYCLE slicer for PETG.
I change the retracts to 325 and 275 respectively. I leave the temperature alone. This seems to do a -whole lot- better than the ABS slicer with 3rd party filaments. The ABS slicer really is formulated for -just- 3DS ABS filament... a special -recyclable- blend. And the great part is that the EKOCYCLE slicer solves this for 3rd party ABS. Essentially, the EKOCYCLE slicer is more gentle with the entire system. More precise.
And yes, I get great OOTB prints with 3DS ABS and the CubePrint ABS slicer. But that is the -only- filament that works.
The submission of files on the USB just puts the file onto the memory card just like WiFi is doing. It is handed over to the 3DS OS once accepted.
- - - - - - - - - -
Your temp profile looks fine. Normally I see within -5 degrees on the read-back. Typically a bit low. But these are normalized values as there are many thermal brakes between the sensor and the nozzle tip. The read-back to the app can also have a huge delay once the the print gets going. Could it be triggered by timestamps or something?
Thanks TD. I decided to try again with the retraction values returned to default, and it is printing much better. So far no weird outdents....
Can I play??
Where do I find the current version?
Are they at the links in Post #1?
More the merrier, John...
Bottom of this post is what I call v20: http://www.print3dforum.com/showthre...ll=1#post46964
Hey John,
The zip file can be found here. There will be an update coming in the next few days with some changes that TommyDee has requested. Please feel free to request any changes you see fit. I try to respond to requests fairly quick, unless they are more involved, then it may take me longer.
Right now, I am working on the design for an app to send Cube3 files to the printer directly (outside of CubePrint).
Got it. That is one nice piece of work, bb!
Kudos to you, and to TD for all the ideas and info.
Future tweak - could the Printer Model be a pull-down list?
If so, then perhaps on selection replace the Firmware/MinFirmware values with the corresponding 'normal' values (1.14B for Cube3, 1.05 for Ekocycle) for the model selected?
The fields could still be edited, if someone wanted to play with Eko version V1.04C, for example.
For PETG I make the .cube3 file with the Eko slicer, then run it on my Cube3 by switching those 3 fields.
Thank you for building this spiffy tool!
...and John, Buddy built a command line interface that integrates a custom script for those -repeat- jobs.
While you are working on this, Buddy, is there a "/help" option in the command line to see the full syntax?
And I've been meaning to ask what the syntax [XML] is for on encode and decode. Does this switch properly decode and encode the config files?
Thanks for helping out there John. Definitely cannot push all the buttons Buddy has provided for us fast enough.
JT -- TommyDee already asked for that and it is next on my list. :)
TD -- I will add help to all the utilities -- is there one you want more than any other, i.e., a prioritized list so that I don't spend my time on the cube extractor and builder, when you really want the editor and script generator.... The XML is so that you can pass in the encoded XML file and decode it, or pass in an unecoded XML and get it back encoded.
This obviously is not his first rodeo!! ;)Quote:
Originally Posted by TommyDee
Definitely need to test the XML thing again. That is still highest on my wish list; config files.
Otherwise, no; Everything you are doing has value at one level or another.
I think the highest order of work is likely in the %-pressure implementation.
That is a CubePro wish list more than Cube3/Ekocycle. Not impossible without it.
Did you have a list you are working from that we can help prioritize?
So, the last list we talked about:
- Add Sidewalk/Support checkboxes (this is done and needs to be tested, and I will push it up tonight).
- Drop down lists for Version, MinVersion, Printer Model.
- I was thinking of modifying the UI, to change the order of the version fields and model field. so that when you select the printer model to CUBE3, EKO, or CubePro, it automatically sets the corresponding version in the Version and MinVersion. If you type something in the model field that doesn't match any of CUBE3, EKO, or CubePro, then it leaves the Version and MinVersion blank
- Adding a Global percentage change for Extrusion pressures ( negative percentage for decrease, positive percentage for increase)
- Change image in combined file to be my icon (to show that this file is modified from original) -- now if I could just figure out the MRL file format.
- Help for command line usage. This is scattered throughout the forum, but I should make sure that each of the utilities has this implemented.
Did I miss any?
- - - - - - - - - -
For the Extrusion pressure change, there would be a script change that would go with it. I think I mentioned that previously as well.
- - - - - - - - - -
Here is the previous list
http://www.print3dforum.com/showthre...ll=1#post47087
I think you got it. 1 is a fit and finish. So far I had not been able to make anything error with these values being different. The info read-back in the apps is the only place I see the material calls for support and sidewalks.
Drop downs, yes, very useful for lazy people :p
Pressure change percentage... high on my personal list for CubePro
Icon is CubePro only and a specific instance (cube/eko going to cubepro). This can be very low on the list as we can output the file without an image even with WiFi. Consider maybe removing CubePro output conversion support directly and look at a stand-alone app to convert Cube3 to Pro. CubePro can be a very low priority in this regard.
MRL files are probably an alpha channel file. However, MRL is also what all the other 'commands' are called in the firmware folder IIRC. Something has to be throwing 'elevation status' from the print file; something like the time stamps weighed against the total time in the header. When you watch this on a cubepro printer, it glitches all over the place. Very poor implementation indeed!
I find application help to be the one thing that bites most people over time. Kind of like the grinch... solve world hunger and then don't tell anyone. I'd say this is a priority. Solving world hunger, that is.
Understood on the script change.
new version posted.
https://drive.google.com/open?id=1gd...mhQ_f28-DhOI6e
First, Second and 5th bullets addressed. Please let me know if you find any anomalies. Each executable now will take -help, /help. -? and /? to get to the help screen. Dropdown for printer model shows CUBE3, EKOCYCLE and CUBEPRO. The Firmware and MinFirmware fields will change accordingly. If you enter a value into the model that is not in the drop down list, like cube3, then firmware and minfirmware are cleared.
The checkboxes for sidewalks and supports are also there and will update the XML and BFB. The logic to only allow each to be assigned to only one color is implemented.
The other bullet I want to add is to get a version on this thing.
...versions are nice :)
A lot more excellent work Buddy. Much appreciated!
And now a version with an "About" dialog that contains a version number!!!!!
https://drive.google.com/open?id=1gd...mhQ_f28-DhOI6e
:D
....22 .. . . ... .
Most Excellent!
Attachment 3373
finished dice tower
Had an interesting thought... and merely a though mind you;
"Z-Shift" - Infinite Cube3 layer thickness.
Say you want to cut the 200um layer to 100um...
You would unilaterally scale your model up to 200% in Z in MeshMixer.
And replace all the Z-values, after the first, to half it's original value in the print file.
Want to start with a little more gap; change all Z-values by "N".
Want 300 micron layers? scale the part in Z at 66.66% and increment Z at 150%
Whatever the scaling factor, the pressure (M108) moves by some factor.
Okay, Cube3 uses 0.1925mm per layer so percentages are based on this.
Of course, a 70 micron print can be applied similarly.
Oh, interesting. And that actually makes some sense. I assume that the movement commands are affected by this, but which ones? How would the M108 be affected?
M108 changes are based on less material to deposit... theory would be an equal percentage to the height change.
Most of the housekeeping commands are M5xx. They have their own code for positions based on calibration settings. There are -out of bound- signatures for wipes but that Z value isn't critical as it is mostly just for a very generous clearance.