Paying for firmware development
-
I'd like to have some custom firmware features added for my specific 3d printer set up. I am wondering if there is anyone out there that could develop these features for me for money. Anyone interested?
One example task could be the repurposing of a motor driver on the Duet to turn a motor at a constant configurable speed (not sure if this is possible, but it must be).
Another task could be the implementation of baby-stepping for other axes with little delay. I tried and I couldn't get it to work with little delay.
Other things I would pay for are screen firmware changes (like adding more popup screens with buttons for sending custom g-code commands).
Anyone want money?
-
We accept contributions towards development to speed up implementation of particular features. Usually these are from OEMs who have an unusual requirement.
The next opportunity we have to implement major new features would be in firmware 2.03, because we are close to releasing 2.02.
-
Working with DC42 would be best, because all additional features become part of, and are maintained with, the "Main Path".
On the other hand, if you do engage someone to code those features*, is that you really need to think about how that contract/person/relationship will maintain those features in the resulting fork as the main code base moves forward. Getting them built is the smallest part.
.
.
*RepRap for Duet is open source. It is perfectly legitimate to fork the RepRap source via any combination of your skills, contracted skills, etc, etc. The underlying relationship of the various coders who work on the fork (volunteer, commercial, etc.) is unrelated to the openness of the code itself. The resulting derivative fork must remain open via the same licence agreements.
Retention of license is part of the license agreements in force now, and at the future moment the code would be forked.
A lot of people's "mental model" of 'open source' equates to 'anything goes'. In fact 'open' is a license agreement that carries many restrictions. Ask for more detail if this is not making sense.
-
Yeah my next questions were about the open source, but you generally answered my questions - the person doing the forking/development, or myself would have to make the modifications available online.
I have actually modified some firmware myself already (custom buttons on the screen for custom g-codes for example) but I have not posted my buggy code on github, so maybe I'm in violation
-
By the way... the constant speed stepper thing: I'd really think about doing that with an Arduino and turning it off/on with a digital IO pin. The M codes are already in place to turn a pin on and off. The arduino piece to run the stepper is less than an hour of code/debug for anyone who's done arduino stepper stuff before. Total cost maybe $40 for the arduino and a driver board...
Question: Do you really need "constant speed", turned on/off with gcode, or do you need "run at xyz speed, set by gcode"?
-
I will have to learn github so I can post my code and it syncs/merges or whatever and all that stuff. Always wanted to learn it.
For the stepper motor thing, I think that is what I will do. I was just kind of giving an example. I'd rather have "run at X rpm" where X is -1000 to 1000 for example and then to change speed optionally when a new g-code is sent. So for example: M499 R-150 turns the motor counterclockwise at 150 RPM. That is one use case scenario. The arduino solution would be fine in this case.
And then I was thinking for a completely different use case: its movement should be coordinated with the normal G1 commands. This would be useful for printing a nice design on a cylindrical surface for example or on an egg or something. So that is why I was thinking it should be run from the duet - because the duet will be able to keep the motion synchronized ... but if I do it from an external arduino, its not necessarily synchronized.
-
Making the movement synchronised is no problem, treat the motor as an additional extruder.
It would be a little more complicated to have a motor rotate continuously without being synchronised, because the firmware is set up to control all the stepper motors in a synchronised fashion.
Have you considered using a DC motor instead of stepper motor to do the continuous rotation, and using PWM to control the speed? That might be an easier solution if you don't need the speed to be accurate.
-
@dc42 yeah I considered it, but then I would lose the ability to synchronize it with the other motors. Maybe I should just have two separate setups - one with a DC motor for the constant speed (unsynchronized), and one with a stepper (which can be synchronized).
-
@jml is the unsynchronized option really required?
-
As DC42 said, synched movement is just another axis. It is literally what a G-Code motion controller does.
Speed controlled stepper via g-code? Use the M code that prints messages on the console and have the Arduino "sniff" the serial port that goes to the PanelDue. Will work with or without PanelDue present. Easy Peasy.
-
Yeah unsynchronized is required because I just want it to keep spinning at a constant speed without slowing down when other axes are accelerating/decelerating.
Maybe I can just make two setups. One with a stepper for synchronized. One with a dc motor for unsynchronized.
Or maybe I can have one setup that has a stepper motor, an arduino, and a stepper driver, and a switch. The switch electrically disconnects the motor wires from the duet's motor driver. And it connects the motor to a different motor driver controlled by the arduino.
