Cube 3 / Pro hacks

I got 5 for you... in PM. I think...

 

Interesting use of the waste energy.

 

How's that?

 

More jobs for you, although not sure if Ekocycle really sold well....

Are EKOCYCLE cartridges compatible with Cube 3?


No. EKOCYCLE cartridge works only with EKOCYCLE Cube 3D printer.

 

With the excellent work you can print on the Cube using filaments ABS, PLA and INF present in the cartridges. I saw that there are new materials for filaments in the ICE site such as HIPS, PET, PVA, FLEX which by their nature can be interesting to use.
Since the Cube uses only the filaments ABS, PLA and INF, I thought for the characteristics of materials using the following settings:
HIPS = cartridge ABS
PET = PLA Cartridge
PVA = INF cartridge
FLEX = cartridge ABS
I wonder if anyone who has experience with these materials with printers REP, when sharing my hypothesis.
Thank you

 

Ekocycle is also limited to 200 micron resolution and has some infill settings disabled (software does not allow you to select them)

 

FWIW, 70 micron on the Cube3 is not desireable so far. But if the firmware from the Cube3 can be "ported" to the Ekocycles, then we're done hehe

 

We're transferring with WiFi.

A test part selecting PLA as material brings the error only after the PLEASE PUT GLUE message sent by the Cubify software.

Im scared to test print it so it will liquify PLA too much due to ABS temp raising too much....


IF POSSIBLE; i'd like to stay away from USB back and forth operations, as printers are in another room and all our printers behave fine via Wifi/Octoprint....

 

So the Cubify software is pinging the Printer somewhere about the material loaded but its getting a wrong answer even if the chip "inserted" is from PLA.....thats weird bc i never loaded ANY ABS cart on this printer and Im the first owner of it.

Are you sure ABS isnt launching the temp too high for PLA?

 

There should be a branch to all watchdog functions that starts at the read of the chip.
If you never verify a cartridge, present or otherwise, you pretty much severed this watchdog function.

Do we want to disable the over-temp function that creates the other prominent Cube 3 error (over-temp detected or something like that).

I try to use WIFI exclusively. My only problem is the printer not staying on the same network or not listening for the host-ping.

And I am very much looking forward to flexible and other materials. Some will be abrasive to the nozzles so they will need replacement from time to time.
I also noticed that the reported temperature from the cube is much higher than the material ratings. It must be reporting heater temps, that is reduced by the time it hits the tip.
But 230 degrees is a fairly normal "info" screen temperature for PLA. Thanks for the tip, Martelli.

Did they ever sell a single Ekocycle? I wonder if Coke pulled out caused facilitating the crash for the entire Cube3 line.
If we break that S/N tie, there should be no reason to keep Ekocycle from being converted to Cube's.

 

As I said earlier.... I activated this factory sealed printer which came with a very early firm. I've never bought abs and I've never fed it with abs.

Perhaps it's a Mac OS issue?

 

Not sure if fully understood you but glad you found the issue. I was about to try generating the print from Windows and see results... via wifi of course.

 

Sounds like there is a handshake between the 4.03 host software and the firmware on the printer.
The problem would be in this handshake which is only required when using the computer UI.
When you stuff the file on a USB stick, the system seems to be doing whatever the UI was doing.

I have a personal preference for leaving material alone as it is nice to confirm what I put in the printer.
Then again, I also have chips for all 3 qualified materials.
Infinity Rinse may or may not have special attributes in the system.

As we apply more patches, studying the use-cases is going to get a lot more complex exponentially.
Earlier, I asked if it was possible to create a firmware flow chart.
This would certainly ease the patch effort as much as it would provide a reasonable view of what to test.
We know everything that is presented to us as users.
These are the decision blocks that should have clear threads to processes.
Other UI interactions is presented on a scheduled basis. As they are identified, they too will help eliminate dangling threads.

No one answered my other earlier questions... is there any logic in the MRL file naming that suggests menu structures?

 

or create three patchers one for each material and let the user decide

or at least send us the PLA forced one for now, please! i dont plan on ABSing at all!

 

I have specific needs for both materials. Then again, V1.0 is nearly perfect for me.
100% cartridges are the only remaining stickler which I can easily get around.

The other side of that coin is not wanting to re-flash on a regular basis.
Somehow that just gives me cause for concern.

 

Yes!

 

Eychei; okay, that I understand.
If we allow any material, and let the print file determine this, we cannot send directly to the printer.
This is when the handshake is done over material. We would have to create the file using the UI (3.04).
Only if the material matches the burned in default will the UI (3.04) let you send over WIFI.
The idea is this... you cannot use the UI to "Print" unless the printer is set up for that print.
Meaning the cartridge is on the appropriate side(s) and cartridges are present with the required material.
A color mismatch will not fail the WIFI print function but does branch off in the Cube to warn of color mismatch.
To change this we will need to hack the computer's UI software.

If the MRL files are graphic files, something should be able to read them and show the image.
And if we can read them, we know which screen it refers to.
Then when you find the call in firmware, you know what routine is active.

One cheat that might work for this... swap the languages around.
Move one file from Chinese to German, for instance, if your language is German.
If it does what I think it will do, you will be using the printer to show the images.
When one screen is no longer German, but Chinese instead, you now know what function that string of MRL files belong to.

I know this is the poor man's way of reverse engineering, but sometimes it is the easiest way.
Are the language files also burned into firmware or are these pinged from the Micro SD?

Also, the graphic percent complete coloring of the image takes on an interesting means of merging images.

Is anyone working on mapping menus to a flow chart?

 

Your wife and mine should go have tea