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.