Topics created by Th0mpy

@EdChamberlain It's working but I've taken small breaks to build some other hardware.

The core of the SB2040 toolboard is working great. I am looking into I2C in order to add an LIS3DH accelerometer, but the I2C libs aren't wired up into the RP2040 yet.

I had a few issues with my environment and now can compile both the 3.5 code for RP2040 and Jay's branch.

Does anyone know when I2C might be ready to test on the RP2040? I'm digging around but I'm getting a little lost.

@VoodooBane I don't know, I haven't seen them online for quite some time. It's pretty simple, however, to update and compile the firmware. To be honest it's been a hot minute since I touched it last.

I was looking around for someone else and either I sold them all or completely lost them in my shop 😄

I am considering a new order of them, if I get enough interest it would push my decision up a notch.

@Th0mpy it does not.
Only the LIS3DH and LIS3DSH are supported

@th0mpy or buy an SKR3. That supports RRF and CAN-FD

@o_lampe you do need the CAN transceivers. They should have low propagation delay because we can't do transmitter delay compensation on the RP2040. And yes, the MCP2542 CAN transceivers that we use on Duets and recommend for the RP2040 are hard to find at present, however the SOIC version is currently available from Microchip Direct.

@th0mpy said in Heated chamber configuration:

What firmware version are you running?

This version needs RRF 3.3 or higher, but the initial config ran under RRF 2.5. Currently, I am at 3.4.0.

@th0mpy said in G30 and deployprobe.g:

What does NOT work is if I issue a command G30 Xnnn Ynnn. I cannot seem to figure out how to use deployprobe AND a G30 command which contains coordinates.

Unless that has changed very recently using G30 like that ignores the X and Y parameters.

I have made a request in the past to implement that capability.

Frederick

@jay_s_uk I do. I am running it stand-alone now and everything seems fine, just the voltage on the 5V rail is a bit low.

@th0mpy only the LIS3DH and LIS3DSH are supported

@th0mpy sorry, I'm being an idiot. Yes, they're the main bearings! I do have the dimensions scribbled down for the idler somewhere...

EDIT:

3x8x4, so look for 693ZZ for the idler

Apologies, it's been a long week!

@pcr I think you still should have a diode on the input right?

Looking for a single header that will power the inductive probe and accept the signal generated. As well, it should be flexible to offer a few different voltages. I thought that a diode would be required to fully satisfy all the requirements.

@dc42 Excellent!!! Thanks for the update! I'll give it a whirl this weekend.

@th0mpy I suggest you use either the 3.3-dev branches of all four projects, or the 3.4-dev branches.

Theoretically it's possible to write a utility program that will takes readings from arbitrary points and will export it as a grid compatible with RRF.

What this utility needs to do is to take the set of points, perform regression to some surface, then sample that surface at grid points and exports the grid to RRF as a .csv file.

If somebody here has a good mathematical background with this sort of things, I don't think it would be too difficult to write.

Alternatively, the program can take a dense mesh sampling with problematic points removed and then estimate them using neighboring points. Again, will require some mathematics.

@th0mpy the additional circuitry on the Mainboard and most expansion boards is to provide the firmware.eith reference voltages to compensate for variations in the analog voltage levels. This leads to more accurate and repeatable temperature readings. The 1XD temp input does not have this so is less accurate than other Duets. That is fine for the application (motor overheating sensor).

Check this page out to see what you can't do atm. https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations

@dc42 I'm glad to know that I'm not crazy (in this particular instance)! Let me know if you need anything, happy to help.

Thanks for reporting this, it should be fixed in the next build.

Glad that's fixed it. Please keep up with the 3.4 releases as they come on the way to the final release just to confirm that it stays fixed.