Modded V-Core Jubilee Bed Mashup
-
Hi all,
Just thought I would share some photos of my current CoreXY build. It's a modified version of the original V-Core with a Jubilee style 3 point kinematic bed mount.
I've just finished installing and configuring the bed mount, pretty happy with how the true bed levelling is performing so far. Not a spring or knob in sight
They aren't the actual Jubilee parts, as I wanted to use the delrin anti backlash blocks rather than the brass ACME nuts and obviously my frame dimensions are different.Mechanically it's all done and working but still got a few things to do:
- A bit of wire management (endless wire management lol)
- Mount the heater and build surface on the bed plate
- Design a part cooling duct for the Hemera, not really a fan of the ones I've seen on Thingyverse so was thinking of designing a tusk style one. If anyones got any suggestions on this?
- First print and tune
I'm also looking at driving some NeoPixel rings from the Raspberry Pi via DSF. I already have some working prototype code for this just need to get it working with all 48 LEDs. Will share more on this as I progress.
-
Look good!
@richardmckenna said in Modded V-Core Jubilee Bed Mashup:
I'm also looking at driving some NeoPixel rings from the Raspberry Pi via DSF.
Bear in mind that NeoPixels are a pig to drive, so the RPi probably won't be able to do anything else (e.g. send GCodes to the Duet or respond to web requests) while sending data to them. That's why the Duet 3 supports DotStar LEDs instead.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
Jubilee Bill-Of-materials actually specs Delrin anti backlash.
VERY nice build!!
-
@dc42 said in Modded V-Core Jubilee Bed Mashup:
Look good!
@richardmckenna said in Modded V-Core Jubilee Bed Mashup:
I'm also looking at driving some NeoPixel rings from the Raspberry Pi via DSF.
Bear in mind that NeoPixels are a pig to drive, so the RPi probably won't be able to do anything else (e.g. send GCodes to the Duet or respond to web requests) while sending data to them. That's why the Duet 3 supports DotStar LEDs instead.
There is a Pi Python NeoPixel lib that uses hardware in a clever fashion and therefore trivial CPU load. I'll look it up later, I don't have a copy of that Pi's SD with me at the moment.
-
@Danal said in Modded V-Core Jubilee Bed Mashup:
There is a Pi Python NeoPixel lib that uses hardware in a clever fashion and therefore trivial CPU load. I'll look it up later, I don't have a copy of that Pi's SD with me at the moment.
That may be possible if the driver uses a hardware SPI interface with DMA, in a somewhat inefficient manner (probably using DMA to transfer 1 byte of data per 1 bit sent to the Neopixels). But check that it doesn't need the same SPI channel that the Duet connects to.
-
That's a very interesting way to implement a kinematic mount! Is it stable?
-
Found it. rpi-ws281x Uses PCM (audio) DMA so it uses all the bits. It can also use SPI, but as you point out, we'd want to avoid that. From the library:
When controlling a LED string of 240 LEDs the CPU load on the original Pi 2 (BCM2836) are: PWM 5% PCM 5% SPI 1%
Should be trivia on a 3B+ or 4
I'll have an example later today or tomorrow, from a project that was not 3D printer related.
-
@Danal said in Modded V-Core Jubilee Bed Mashup:
Jubilee Bill-Of-materials actually specs Delrin anti backlash.
Ah yes, I mean the rectangular delrin block type with the grub screw at the top.
@dc42 @Danal Thanks for the warning about SPI. I'm actually writing the application in .net core so I can make use of the DuetAPIClient to subscribe over sockets. I actually started with Python but was struggling to find a good way of parsing the socket messages as you need to know the length of each message.
I'm using a C# wrapper for a C assembly by Jeremy Garff (I think this is the same library used by the python package) to control the LEDs. https://github.com/jgarff/rpi_ws281x which allows control via PWM, PCM or SPI (uses SPI driver "/dev/spidev0.0").
Also the NeoPixels are connected to Pin #40 / GPIO21 via a split ribbon cable (can be seen in the 3rd photo) which I believe is not an SPI enabled pin. So I believe I'm using PCM.
In my testing (admittedly nothing to complex yet) I have not noticed any slow down on DWC or issuing commands.The Pi 3 B+ seems to handle it quite well, with CPU usage very low.
Here is my initial code which changes the LED colour based on the status of heater 1 (Bed). https://github.com/richard-mckenna/DSFNeopixelStatus
@mrehorstdmd said in Modded V-Core Jubilee Bed Mashup:
That's a very interesting way to implement a kinematic mount! Is it stable?
From my testing, yes, very stable. Obviously you can lift it up. Like the Jubilee I plan on installing springs under each mount to stop that. But in every other direction there is no movement at all. I think what is. genius about it, is that it allows free rotational movement when adjusting the 3 z lead screws independently.
-
That is the library, and GPIO 21 means you are using PCM. Good stuff.
@richardmckenna said in Modded V-Core Jubilee Bed Mashup:
DuetAPIClient to subscribe over sockets
Are you desiring to interact with the web socket or the in-memory socket? Here is a python library that works with the in memory socket (and some examples):
-
@Danal yes that’s the python code I was looking at initially, didn’t twig it was yours sorry.
Yes, unix socket, so in memory. The problem I had was that you need to set the length of the expected message
self.DCSsock.recv(2048)and in subscription mode the length of the message varies depending on what has changed in the model.If you set the message length too small you end up loosing part of the message and can’t parse it. If you set it too high the messages actually start merging together.
I believe the best way of doing sockets with python is that the server prepends the message with a fixed length header which indicates the length of the message. That way you can set your buffer size to a fixed size and identify when an entire message has been received.
-
Actually, that effectively acts as a max. Or phrased another way, they don't merge together (that I've ever observed).
Having said that, I've been focused on command mode, not on the object model. Is that where you are seeing the merge?
-
@Danal yeah, I found that if the message was smaller than the set buffer it would merge some messages together. At some point I’ll see if I’ve still got the code so you can see how it behaves. Would be good to find a solution and have all 3 socket modes in your library.
-
Having thought about this some more, I actually HAVE seen certain responses merged. Never a command response, but yes, sometimes, things like the 'version' that is emitted on an initial connection and the 'success' from the the command (not the command response, just the... well... i'd call it a 'control channel' response, but that is probably technically incorrect terminology).
My approach is/was to regard everything as a stream and parse without regard to buffer boundaries. Phrased another way: Separate transport from content semantics. Works only because all responses are JSON.
-
Oh, and I'd love to see your code and expand the PythonDSF connector.
-
@richardmckenna said in Modded V-Core Jubilee Bed Mashup:
@Danal said in Modded V-Core Jubilee Bed Mashup:
Jubilee Bill-Of-materials actually specs Delrin anti backlash.
Ah yes, I mean the rectangular delrin block type with the grub screw at the top.
@dc42 @Danal Thanks for the warning about SPI. I'm actually writing the application in .net core so I can make use of the DuetAPIClient to subscribe over sockets. I actually started with Python but was struggling to find a good way of parsing the socket messages as you need to know the length of each message.
I'm using a C# wrapper for a C assembly by Jeremy Garff (I think this is the same library used by the python package) to control the LEDs. https://github.com/jgarff/rpi_ws281x which allows control via PWM, PCM or SPI (uses SPI driver "/dev/spidev0.0").
Also the NeoPixels are connected to Pin #40 / GPIO21 via a split ribbon cable (can be seen in the 3rd photo) which I believe is not an SPI enabled pin. So I believe I'm using PCM.
In my testing (admittedly nothing to complex yet) I have not noticed any slow down on DWC or issuing commands.The Pi 3 B+ seems to handle it quite well, with CPU usage very low.
Here is my initial code which changes the LED colour based on the status of heater 1 (Bed). https://github.com/richard-mckenna/DSFNeopixelStatus
@mrehorstdmd said in Modded V-Core Jubilee Bed Mashup:
That's a very interesting way to implement a kinematic mount! Is it stable?
From my testing, yes, very stable. Obviously you can lift it up. Like the Jubilee I plan on installing springs under each mount to stop that. But in every other direction there is no movement at all. I think what is. genius about it, is that it allows free rotational movement when adjusting the 3 z lead screws independently.
Yes I like this mount design too, for the reason that the linear carriage and the lead screw are all separated from the bed, which should mean efficient expansion compensation.
I'll be using v slot rollers, but hope to connect both the lead screw nut and some sort of sliding shoulder bolt straight to the roller bracket, and having a ball joint on the bed itself.
Hopefully this should remove all effect of the aluminium bed (in my case 400x400) expanding and contracting.
-
@Corexy The approach I used was to put insulation under the aluminium plate and bolt the plate to a Vslot frame. Then connect the lead screw mounts and Vslot linear guides to that frame. So the plate might expand but the frame itself remains relatively cool. I used two thicknesses of semi rigid insulation of the type that is used for electric under floor heating giving me 12mm of insulation. The bolts are countersunk in the plate. I made stand off pillars, 12mm tall and fitted them in holes in the insulation. So the only thermal transfer happens through these stand offs and the bolts.
The upside is that you don't have to worry about using kinematic mounts to take care of any thermal expansion - at least it works for me. Also, that sandwich arrangement will hold the silicone heater in place if (when) the adhesive lets go.
The downside is that it takes forever for the bed to cool. That's not an issue for me because I use removable glass print surfaces.
