Cura: JSON for Delta Machine?

[CCS86]

Hi guys,

Does anyone have a JSON for a delta machine? It looks like the key settings besides gcode flavor, would be center is zero, bed shape round, bed diameter. I have found the first, but don't know what the others are called, or anything else I am missing.

"machine_center_is_zero": { "default": false },

Thanks!

[Ghostkeeper]

We don't have machine settings for any delta machine yet. There has been some want for it in the community but we haven't been able to add one yet.

To set the bed diameter, you'd have to use machine_width and machine_height. Then to make the bed round, you'd have to add a polygon to machine_disallowed_areas in order to approximate the round shape. There is no 'real' support for a round bed, only with these machine_disallowed_areas.

For an example of machine_disallowed_areas, take a look at ultimaker2.json. It defines 4 disallowed areas for where the metal clips are on the bed.

[CCS86]

Thanks! any plans to add a bed shape parameter like old Cura?

[Ghostkeeper]

I haven't heard of such plans yet, and I don't think they'll come any time soon, since the machine_disallowed_areas method works all right.

[CCS86]

Do you mean something like this?

It doesn't seem all that straightforward, vs just defining the bed area to be circular.

[Ghostkeeper]

Yes, that's what I meant. It's not ideal.

[onitake]

I made a little script to calculate the keepout polygons: https://gist.github.com/onitake/78a35293501b03c2dd72c9ab5dede1db

It looks like Cura will use the convex hull of any keepout polygon internally, so I generated it as a triangle fan instead.

And here's an example JSON for the Rostock mini: https://gist.github.com/onitake/f94722ec6cfccb8d3f6adaebb63b7283
It's completely untested and may be missing important settings, though.

[CCS86]

Awesome, thanks!

[onitake]

I was able to run some tests, and the results look very promising.
One important thing I noticed is that Cura adds 10mm on each side of the bed and keepout area, so I increased the limits to 180mm for my 160mm bed.

_Edit:_ Updated the gist

[onitake]

If you don't have a heated bed, make sure to set machine_heated_bed to false, or Cura will try to preheat the bed and wait forever.

[nallath]

Cura doesn't add 10mm as a keepout area unless you select brim / raft for platform adhesion and set it to 10mm. Don't increase the size! This is very much intentional behaviour as stuff is printed there and that should be inside the build volume.

[onitake]

Ah, that explains it.
The test object I want to print has a width of about 135mm, and with the brim set to 0-2mm, it will just fit.
Thanks, I'm still a total noob when it comes to 3D printing.
I replaced the gist again.

Now, I encountered a different issue: The print head seems to be moving way too fast, but only for some outlines. This leads to too little material being deposited and the print becoming warped because it doesn't cool down fast enough.
Interestingly, support structures print at adequate speed. Which parameters do I need to tweak to fix this? Should I just decrease the overall print speed or is there a more specific way? Would decreasing the Flow value help (so Cura compensates more)? Is there a way to limit this in the machine definition, independent of the material properties?

[Ghostkeeper]

In the Speed category, click the little gear to enable the visibility of some extra speed settings. There's "Wall Speed" there, which determines the speed of the outlines. There's also sub-settings so you can set the speed of the outer wall different from the speed of the rest of the walls. Outer wall speed should be very slow (10-20mm/s) because its quality is most visible.

If it only happens on the first few layers, take a look at the "Initial Layer Speed" setting.

Maybe with outlines you meant the skirt, the outline it draws around the model on the first layer. The speed of the skirt should be about the same as the overall speed.

In the machine definition you can set settings independent of material properties, by adding them to the category "overrides". Take a look at the machine definition of Ultimaker 2 to see how it's done.

[onitake]

Thank you, Ghostkeeper.

I used the default "Normal" profile, with the following speeds: Print = 60, Infill = 60, Shell = 30, Outer Shell = 30, Inner Shell = 60, Top/Bottom = 60, Support = 60, Travel = 120.

My impression was that the supports were printed at normal speed, while shells (I meant the shells when I wrote outlines before) were printed roughly at the same speed as the infill - and travel speed was about the same too. But that doesn't agree with these numbers. I'm going to try 30mm/s for all shells and see if it changes anything, then 60mm/s for travel. Perhaps there's a bug somewhere and the speed doesn't change properly after travel?

Oh, and I don't have an Initial Layer Speed setting. There is only Initial Layer Height.

[onitake]

Ok, it looks like speed was not a problem after all. The filament thickness was wrong. With the correct value, I'm getting much better results.
I'm still a bit confused about why the support structures print so much slower, though.

[Ghostkeeper]

Just got a report from someone internal who got a similar problem. In the g-code it set F60, meaning that it'll move at 1mm/s. Definitely erroneous.

[onitake]

I found that my printer gets stuck if you set the speed too high, so I added overrides for speed_print and speed_travel to limit the maximum speed.

The print speed of the supports still seems to be a problem. They always print much slower than the rest. Should I open a bug report for this?

[Ghostkeeper]

You had a modified Prusa I3, right? I'd love to know what your maximum speed has become. I could add that to the I3's machine definition.

I've created an issue on the support speed in our internal issue tracker (which is closed from the public for now due to future Ultimaker products being tracked there too). For reference of our developers, the ID is CURA-1389.

For now we can leave it at this, but if you'd like to continue discussion on the support print speed I suggest we move over to a new issue, as to not taint this one further.

[onitake]

I don't know, I got it from a friend when he bought a larger model a while ago.

It's very similar to this one, but without the heated bed and a simpler head assembly.
My friend says it's a clone of the Rostock mini.

Correct me if I'm mistaken, but the Prusa i3 isn't even a delta printer???

[nallath]

The Prusa i3 isn't a delta.

[onitake]

150mm/s seems to be too much for my Rostock mini, but I haven't determined the precise limit yet. Need to do some more testing.

Updated rostock-mini.json again, with the speed limits and some small tweaks in the end Gcode (retract head and display a message).

[onitake]

@Ghostkeeper It seems the support printing speed issue has been fixed?
I just pulled the latest commits of Cura and CuraEngine and the supports print much faster now.
Thanks for fixing!

[Ghostkeeper]

@BagelOrb reported that the bug was caused by faulty profiles and has indeed been fixed now.

[onitake]

I may have found another bug, or maybe it was an incorrect setting or a firmware bug in my Rostock:
The heating seems to be turned off while printing the raft, or at least for some time. This causes a temperature drop and clumping. It's not too serious, but can cause stability problems.

[BagelOrb]

@onitake That seems like a separate issue. Please file new issues in new threads.

[onitake]

@BagelOrb Yes, of course. Sorry for abusing this thread as a discussion forum.
I'll investigate a bit more before creating a bug report, as I've noticed calibration/bed distance problems that could also be causing the the clumping, and the seemingly disabled heater could be a Rostock firmware issue, or simply the display and notification LED not updating fast enough.

I'll still keep reporting progress with my Delta experiments here, if that's ok.

[dmopalmer]

My attempt at a Rostock Max V3 (Ooo, aren't you fancy!) is at

https://gist.github.com/dmopalmer/a26081c86bf73613904857a24247f636

I haven't managed to print anything with it because:
1) I don't know how to make Cura 'drop' an object onto the bed once it is flipped
2) I couldn't find the print command (Is that only enabled for Ultimakers, and everyone else has to send the GCode to another program?)

You have to set the filament diameter manually. I may have that setting in the wrong place in the JSON file, or the filament file may be overriding my override.

[onitake]

1) Cura should stick objects to the surface automatically. If it isn't, you may need to turn it around a bit, to maximise the touching surface.
2) You should be able to print with any generic 3D printer just fine. Cura has built-in support for saving Gcode to a file, writing Gcode directly to removable memory (i.e. SD cards) and even communicate via a serial (or USB-serial) port. Event hotplugging works. If it isn't detecting your devices, you may have to check your permissions. Run Cura from the command line and see if it prints any error message.

[BagelOrb]

I'm sorry to say your json is outdated. The format has changed quite a bit
since cura 2.1. Download Cura 2.3 beta and see what the .def.json files
look like.

Good luck!

Op 7 okt. 2016 20:13 schreef "Gregor Riepl" [email protected]:

1) Cura should stick objects to the surface automatically. If it isn't,
you may need to turn it around a bit, to maximise the touching surface.
2) You should be able to print with any generic 3D printer just fine. Cura
has built-in support for saving Gcode to a file, writing Gcode directly to
removable memory (i.e. SD cards) and even communicate via a serial (or
USB-serial) port. Event hotplugging works. If it isn't detecting your
devices, you may have to check your permissions. Run Cura from the command
line and see if it prints any error message.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/537#issuecomment-252322979, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIe9Ec64Y8tT0kuE2Msd2EY-zeqHGaPpks5qxovZgaJpZM4GhaPE
.

[dmopalmer]

I have put a file in the new .json format on the gist. It works with Cura 2.3 beta. This version has a bit of business in the start gcode to extrude and wipe. (The original gcode just squirted at the origin and didn't wipe, which is more acceptable in a cartesian machine where the origin is at the corner fo the build instead of the center.)

https://gist.github.com/dmopalmer/a26081c86bf73613904857a24247f636

Sorry for treating this as a discussion board but:

Where is this file supposed to go? On the Mac at least, the user shouldn't dive into /Applications/Cura.app/Contents/Resources/resources/definitions , it should go in ~/Library/Application\ Support/Cura/ or somewhere like that.

Cura sticks the object to the surface. When playing around with the start gcode, I found an anomaly that leaves the Z axis offset by a considerable amount (not with the current start gcode).

Cura can sometimes connect to the printer (directly USB connected) but usually not. I notice that when I start from the command line it logs a debug statement: Attempting to connect to printer with serial /dev/cu.usbmodemFD1461 on baud rate 115200 which is the right port but the wrong speed (250000 is what my printer expects).

[Ghostkeeper]

It's attempting various baud rates. Only when it receives a valid temperature back from a temperature request will it save that baud rate. You'll see an attempt in the log for each baud rate.

I expect that the definition file can go in ~/Library/Application\ Support/cura/definitions, but I'm actually not 100% sure about that.

Note that CuraEngine will leave out any layers that have no g-code in them, so if your object is very thin on one side and you turn that side down, there will be an offset. Otherwise there is no known bug with the offset on the Z-axis.

[Ghostkeeper]

If you think the Rostok is worthy, we could add it to Cura for version 2.4.

[awhiemstra]

I expect that the definition file can go in ~/Library/Application\ Support/cura/definitions, but I'm actually not 100% sure about that.

Yes, this should work. The resources system first checks any files in the data storage location (~/Library/Application Support/cura on OSX) before it uses those in more "static" locations. This even means that if you want to make changes to a file shipped with Cura you can put it there and it should use that version. (In theory - I have not tested this with definitions yet.)

[dmopalmer]

The 'starts in mid-air' bug seems to be a problem in the Rostock, not in Cura. By making non-significant small changes (e.g. leading zeros) in the G-code, I could change this behavior, and I was using Repetier Host to send the G-Code so it is not a Cura problem at all.

[dmopalmer]

Unplugging and replugging the printer gives the message Attempting to connect to printer with serial /dev/cu.usbmodemFD1461 on baud rate 115200 but doesn't produce any further debug messages. (It doesn't continue trying Baud rates until it hits the correct 250k value).

I don't see where in the code (USBPrinterOutputDevice.py: USBPrinterOutputDevice. _connect() ) it drains the input port of residual detritus (boot messages etc.) before looking for a valid response to the temperature.

Inserting lines

            self._serial.write(b"\n")
            time.sleep(0.1)
            while self._serial.in_waiting != 0:
                nbytes = self._serial.in_waiting
                residue = self._serial.read(nbytes)
                Logger.log("d", "Read %d unexpected bytes from serial port: %s", nbytes, residue)
                time.sleep(0.1)
            self._sendCommand("M105")  # Request temperature, as this should (if baudrate is correct) result in a command with "T:" in it

Shows that 328 residual garbage bytes are received from the port.

Further logging shows that the _readline() never returns.

[onitake]

I also think the Rostock is worthy (of course, I've got one myself ;)

However... There are many different variants of the Rostock available, with different bed sizes.
I think some kind of scaling option in Cura would be nice. The way things are now, the keepout needs to be recalculated manually when the bed size changes. That's not so great...

[dmopalmer]

Not-quite-working. Fix to non-connection problem.

The fixed file is in
https://gist.github.com/dmopalmer/93b4bf0f98c5bf874403e837494fd246
USBPrinterOutputDevice.py:USBPrinterOutputDevice._connect . Merge and incorporate. (I don't know your specific build system, so I have been hacking on the distributed beta, not the git repository version, so I can't do a pull request. Also, there is a lot more diagnostic logging than you probably want. I would attach it as a file, but github doesn't support that for .py files.)

The Rostock firmware continually sends 'wait\r\n' once a second when nothing else is happening.

When the baud rate is wrong, that corresponds to garbage, once a second.

When serial.readline() runs, the timeout value is how long it waits for a character, not how long it waits for a line. So readline() never times out (because there is never a 3 second interval when there is no character) but it never returns (because the corrupted character it receives is never \r or \n).

So the attached code:
1) Drains the serial port after opening it to eliminate the start-up messages.
2) Sets the timeout to 0.1 before trying to readline()
3) Only sends an M105 if there is no data already in the serial input queue (to avoid command/response getting out of sync if an additional line is emitted by the Rostock.)

[dmopalmer]

There was a bug (inverted comparison) in the original of the fix I just put in.

New Gist:
https://gist.github.com/dmopalmer/b3b1dd5cd1a945ab398fa0207ca70ec1

It doesn't work well, but it does connect. I think there are still communications problems.

[Ghostkeeper]

There's a time-out being set on line 346 too, to 0.5. Perhaps it's good to set the time-out to 0.5 on line 336 (still safe from the 1s time-out on the other side) and not any more on 346.

Looks like this would not break anything for other printers. If this is the case, I'm saying we merge this into master.

[paboman]

Hi, I have created my own json profile based on the kossel one which I have found in C:\Program Files\Cura 2.3\resources\definitions
But after launching the software our printer doesn't show up in Cura 2.3.1 printers list, what am I doing wrong ?
thx!

[fieldOfView]

what am I doing wrong?

Well, for one thing you are posting logs nor your edited definition...

[fieldOfView]

Also note that Cura 2.4 has support for circular bedshape, Cura 2.3 does not.

[paboman]

I installed now 2.4.0, duplicated the kossel profile and changed id and name to Atlas.
Copied the json file into C:\Program Files\Cura 2.4\resources\definitions but still cant see the atlas in the dropdown menu.

[nallath]

Did you change the name of the file?

[paboman]

yes, i named it atlas.json
the file name is the same as the "id" and "name"

[Ghostkeeper]

Try naming it to atlas.def.json.

If that doesn't work, show us the log file and we'll be able to help you better.

[BagelOrb]

I think this is solved.

[nallath]

It is, we now have a buildplate type for delta machines.

[onitake]

Yes!
I've been using it for a while and it works like a charm.

The transparent parts of the 3D model look a bit awkward when drawn on top of each other, maybe the model could be simplified. But this is just cosmetic.

Thanks!

[Ghostkeeper]

Sometimes the model mesh is too high, such that it reaches over the "build plate" (square grid) into the build volume, or starts z-fighting with the build plate. When I see that I just fix it by moving the build plate model a millimetre down.

[onitake]

It's actually not that big a problem - the model and build plate look fine.
But the base has too many surfaces stacked on top of each other, and that makes it look odd when rendered with transparency.
Removing some of the interior surfaces would improve visual appeal.