Cubepro gcode

Post Reply
loffler
Posts: 9
Joined: 06 Jan 2015, 10:21

Re: Cubepro gcode

Post by loffler »

I manually added a G4 P2 line to the gcode prefix. I originally thought it was in milliseconds but it appears to be full seconds.
There is already a G4 P0 line in there somewhere which you might be able to modify, but I added an extra line around the wipe sequence somewhere. I cant remember where now as I also changed the wipe sequence back to the original cube one. There are additional movements added to assist the removal, but I found it actually made it worse with threads getting stuck to the barrel etc. You can decode a proper file to get te original movements.
Lsutehall
Posts: 8
Joined: 18 Dec 2014, 11:44

Re: Cubepro gcode

Post by Lsutehall »

Hi guys,

I've just tried the setting posted by MichaelHerron, but with no luck - I get filament errors F11 and F12.

Has anyone else had any trouble? Do I need to alter anything to make it work (For example, I noticed that the filament diameter is set to 3, but i believe that the cubepro takes 1.65mm)

Have tried both with and without cubeitmod.

Thanks!
rassilon50
Posts: 10
Joined: 31 Jan 2015, 15:02

Re: Cubepro gcode

Post by rassilon50 »

Hi, I managed to take the settings directly and make it work.

According the manual, they are filament errors caused by a tangle or blockage.

maybe try a different cartridge? Or just try forcing it to extrude a bit?
loffler
Posts: 9
Joined: 06 Jan 2015, 10:21

Re: Cubepro gcode

Post by loffler »

Also make sure you are using the latest beta of Kisslicer, The older stable version has different settings, so I dont think these settings will work with it.
They worked to a decent level right out the gate, but importantly for me, I needed to add to the z gap to make the first layer 0.40.
Without it, the nozzle is too close to the bed and can give you filament errors.
Lsutehall
Posts: 8
Joined: 18 Dec 2014, 11:44

Re: Cubepro gcode

Post by Lsutehall »

Still no joy, but not had a lot of time to work on this recently.

I see that firmware 1.10 is out now - has anyone updated to it? anything to report?
rassilon50
Posts: 10
Joined: 31 Jan 2015, 15:02

Re: Cubepro gcode

Post by rassilon50 »

Thats the firmware I'm on.

It's just added options for Nylon, but thats about it.
loffler
Posts: 9
Joined: 06 Jan 2015, 10:21

Re: Cubepro gcode

Post by loffler »

Im on 1.10 too and doesnt effect the use of kisslicer. It also adds preview images to the front touch panel.
This complicates things a bit when you try and decode a cubepro file as you have to rip the temporary cubepro file before hitting OK on the summary screen. It must embed the extra info into the final file and include things codex cant decode yet.
MichaelHerron
Posts: 10
Joined: 20 Feb 2015, 16:35

Re: Cubepro gcode

Post by MichaelHerron »

You will also get filament errors if you try to extrude too fast or if you are under-heating the nozzle.
You still must set your filament diameter, nozzle width and extrusion width in the settings.
measure the filament, but it should be around 1.75mm. Nozzle width--thanks to Loffler--has been confirmed at .38mm. I set my extrusion width at .40mm

I've been playing recently with Simplify3D. It is a great program, but it definitely has its issues with this hardware. I'm working on getting multiple material extrusions out of it, and made very good progress last week, but have run into a serious issue--my #1 extruder nozzle broke off..
The progress was in Simplify, but the tool-change code should work in either program.

In the mean-time, until better support for BFB style printers is added natively to Simplify, I'd probably recommend sticking with kisslicer. Simplify has some great advantages and might be right for some... Its main issue is that extruder speed must be set in the gcode header. This means extrusion rate is fixed--manually. It is not automatically calculated based on speed and extrusion width. This means YOU must dial it in, then print at that speed. Once BFB style printers are better supported, the program can calculate this and vary this it can with other printers.
Kisslicer better supports BFB style printers. It also has better in-fill patterns.
duaneh
Posts: 23
Joined: 21 Nov 2014, 13:34
Location: Utah, USA

Re: Cubepro gcode

Post by duaneh »

Hey, everyone. In reading through the posts, it don't see that anyone has managed to completely disable the cartridge dependencies with later Cube printers (Cube2, pro, etc). If there isn't a software method, those who are hardware-savvy might try this:

1. Get a 5V, 5W zener diode or 5V unidirectional transorb.
2. Typically under the cartridge is a board with extra connectors on it. If available, use those, ohming out the connections to determine which pins go to the cartridge contacts. In any event, measure the voltage on the cartridge contacts, noting which is positive (If you don't know what I'm talking about, you should probably get a tech to help ;) )
3. install the zener diode with the band end to the positive cartridge contact, and the other end to the 2nd contact.

The chip used in the cartridges is a Dallas iButton chip. It reads and writes with either 3.3 or 5V, but requires 12V be applied for a short time to write data to the chip. The zener diode will stop the voltage from getting above 5V, and thus prevents the writing of the new data to the chip, but does not affect the reading in any way. Since the chip is a "write-once" part (you can program a bit from '1' to '0', but not back to '1'), they can't perform a write test on the cartridge or the test could potentially use up all the writes available to the chip.

I used this method on my CubeX Duo before I discovered Kisslicer.
Duane
MichaelHerron
Posts: 10
Joined: 20 Feb 2015, 16:35

Re: Cubepro gcode

Post by MichaelHerron »

The DS28E1 chip used in the cartridges reads and writes at the same voltage. It also doesn't appear to have a limitation on number of writes--AND the write is verified in the chips "scratchpad" prior to being transferred to non-volatile memory.

This trick will not work in current cartridges.

Hacking the chip seems unlikely.

Here's a few bullets from the datasheet:

1024 Bits of EEPROM Memory Partitioned Into
Four Pages of 256 Bits
♦ On-Chip 512-Bit SHA-1 Engine to Compute 160-
Bit Message Authentication Codes (MACs) and to
Generate Secrets
♦ Write Access Requires Knowledge of the Secret
and the Capability of Computing and Transmitting
a 160-Bit MAC as Authorization
♦ User-Programmable Page Write Protection for
Page 0, Page 3, or All Four Pages Together
♦ User-Programmable OTP EPROM Emulation Mode
for Page 1 (“Write to 0”)
♦ Communicates to Host with a Single Digital
Signal at 15.3kbps or 90.9kbps Using 1-Wire
Protocol
♦ Switchpoint Hysteresis and Filtering to Optimize
Performance in the Presence of Noise
♦ Reads and Writes Over 2.8V to 5.25V Voltage
Range from -40°C to +85°C
Post Reply