Mightyboard support

[TBSliver]

Hi,

Have been looking at how to add mightyboard support recently, as have got access to a Replicator clone - however have run into several issues. Main one is, there is no support for MCP4018 I2C digipots for stepper motor current setting. Obviously this will need to be added, and am willing to do the work, however there also doesnt seem to be a logical place to start adding support for a new board in.

After looking at both the Development and Release branch, there doesnt seem to be some logical place to put any new work, especially for adding a new Board support, as the pins definition location has changed between the two. There also seems to be a lot of commits between Development and Release, which makes me wonder if the Development branch is stable enough to base new work of. Is there a particular commit ID which would probably be best to start from?

And in regards to 'Why not use Makerbots software', well a Replicator clone is going to get nearly zero support in their Makerware closed source software, and has anyone actually tried using ReplicatorG recently? Especially compared to Cura or even Slic3r... Also, theres no support for part cooling fans in ReplicatorG...

[uhrheber]

Am 16.07.2015 um 11:03 schrieb Scott Lahteine:

There has been a lot of focus on the thermal protection in recent weeks, making it enabled by default for subsequent releases and attempting to improve the algorithms. The new code still gives some false-positives, but it's about 90% there. Enabling WDT by default should probably be included as part of that initiative. While this is a good thing, I don't think that you can build a safe system using only one standard microcontroller. You would either need a safety-enhanced microcontroller (in the best case a micro with two cores in lock-step), an external supervision chip with seed/key watchdog and voltage monitoring, or an additional microcontroller that acts as an intelligent watchdog.

I've thought about this for a while, and I think that the cheapest way would be to use a separate Arduino (micro or nano), that acts as a watchdog for the main micro, monitors the supply voltages, the voltages of all heater, and ideally has separate temperature sensors for all heaters. This may give us SIL1, or even SIL2, if we use clever programming.

[thinkyhead]

I don't think that you can build a safe system using only one standard microcontroller.

But, those are the systems that we are building this firmware for. When cost comes down and more machines have redundant processors, then we can look at this. But it will be a very long time before your average RepStrap is built this way. Hardware vendors are of course free to add a redundant board to control heating, and they should submit their solutions for consideration.

[thinkyhead]

I consider this topic still open and viable. But with our new split-repository system here, we should probably move this conversation over to MarlinDev.

At this point, using Sailfish (especially Jetty) as a reference, we should be able to make a proper pins_MIGHTYBOARD.h file and get started on the needed code elements.

Obviously some preliminary steps are needed before we can support these boards properly. Some of the concerns raised about current limits can be worked-around with smart configuration settings. Other needs —like hardware PWM, MCP3018 support, Adafruit's MAX6675 library — have yet to be explored in Marlin at all.

We should use the new thread to figure out important details like which pins are available for hardware PWM versus which are not (due to interrupts or timers), and how to talk to multiple MAX6675 units. This is a good time to get Mightyboard support started, as I'm also examining Sailfish/Jetty to see how they implement JKN Advance. And there's a feeling in the air that many users of these machines want to get away from RepG and expand their options.

[thawkins]

I have a flashforge with a 2560 mighty board in it, I may be interested in getting it working in Marlin. Having said that sailfish is remarkably capable, and sets a very very high bar.

One of sailfish's big pluses is its gcode analog is very very low level, working only in stepper pulses. The drivers which are on the host, translate gcode into the s3g format which is very very efficient. The only downside is the PC side driver has to know about the steps/mm as it does all the conversions. On Feb 27, 2016 11:33 AM, "Scott Lahteine" notifications@github.com wrote:

I consider this topic still open and viable. But with our new split-repository system here, we should probably move this conversation over to MarlinDev.

At this point, using Sailfish (especially Jetty) as a reference, we should be able to make a proper pins_MIGHTYBOARD.h file and get started on the needed code elements.

Obviously some preliminary steps are needed before we can support these boards properly. Some of the concerns raised about current limits can be worked-around with smart configuration settings. Other needs —like hardware PWM, MCP3018 support, Adafruit's MAX6675 library — have yet to be explored in Marlin at all.

We should use the new thread to figure out important details like which pins are available for hardware PWM versus which are not (due to interrupts or timers), and how to talk to multiple MAX6675 units. This is a good time to get Mightyboard support started, as I'm also examining Sailfish/Jetty to see how they implement JKN Advance. And there's a feeling in the air that many users of these machines want to get away from RepG and expand their options.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2051#issuecomment-189570234 .

[thawkins]

Note: most mighty boards you buy as spares from people like geeetech and monopole, are 1280 based, the ones in all the flashforge and Wanahou machines in recent years have all been 2560 machines. On Feb 27, 2016 11:57 AM, "Tim Hawkins" tim.thawkins@gmail.com wrote:

I have a flashforge with a 2560 mighty board in it, I may be interested in getting it working in Marlin. Having said that sailfish is remarkably capable, and sets a very very high bar.

One of sailfish's big pluses is its gcode analog is very very low level, working only in stepper pulses. The drivers which are on the host, translate gcode into the s3g format which is very very efficient. The only downside is the PC side driver has to know about the steps/mm as it does all the conversions. On Feb 27, 2016 11:33 AM, "Scott Lahteine" notifications@github.com wrote:

I consider this topic still open and viable. But with our new split-repository system here, we should probably move this conversation over to MarlinDev.

At this point, using Sailfish (especially Jetty) as a reference, we should be able to make a proper pins_MIGHTYBOARD.h file and get started on the needed code elements.

Obviously some preliminary steps are needed before we can support these boards properly. Some of the concerns raised about current limits can be worked-around with smart configuration settings. Other needs —like hardware PWM, MCP3018 support, Adafruit's MAX6675 library — have yet to be explored in Marlin at all.

We should use the new thread to figure out important details like which pins are available for hardware PWM versus which are not (due to interrupts or timers), and how to talk to multiple MAX6675 units. This is a good time to get Mightyboard support started, as I'm also examining Sailfish/Jetty to see how they implement JKN Advance. And there's a feeling in the air that many users of these machines want to get away from RepG and expand their options.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2051#issuecomment-189570234 .

[jbrazio]

Getting the G-Code translated into a whatever binary file in the name of performance makes no sense IMO, the current technology bottleneck in terms of speed is not on the firmware and taking that path only brings more issues, like you pointed out, than advantages.

At the end of the day I fully support freeing up all those Mightyboard users so kudos for everyone in the effort.

[thawkins]

A 16mhz 8 bit AVR is operating on the very very edge of its performance when trying to print at higher speeds like 100-120mm/sec. The pulse trains it is generating have to be produced by the ISR, (interrupt service routine), the time it takes inside the ISR determines the maximum pulse rates it can create.

Anything that can be done to offset work from the controller would be a benefit. It's one of the main reasons why everybody is moving off to 32bit controllers running at 70-100mhz. We are probably on the last dying gasps of the 8-bit controller generation. A common pattern now is to pair an 8-bit controller with a 32 bit non real-time device like a Raspberry Pi, with control and spooling code running on the pi.

Many mighty board users are switching to Octopi driving thier machines, as there is a GPX plugin now that does all the precalculation on the fly allowing the raspberry pi to accept near standard gcode, and spit out S3G protocol at the backend in real-time. Building a Raspberry into the base of your printer is a common project for Makerbot, Flashforge or Wanahou owners. Tools like S3D and Cura also support S3G directly (using the GPX driver).

It's highly unlikely that Marlin could get near the performance of Sailfish, as it's trying to do much more on the same resource.

The reason why I mentioned it was because it's an interesting concept, partitioning the firmware between the host machine and the controller, Sailfish's partitioning is pretty smart, and makes the firmware much simpler, freeing up resources for performance gains, as its not having to work in physical units all the time. On Feb 27, 2016 7:40 PM, "João Brázio" notifications@github.com wrote:

Getting the G-Code translated into a whatever binary file in the name of performance makes no sense IMO, the current technology bottleneck in terms of speed is not on the firmware and taking that path only brings more issues, like you pointed out, than advantages.

At the end of the day I fully support freeing up all those Mightyboard users so kudos for everyone in the effort.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2051#issuecomment-189621149 .

[jbrazio]

Don't get me wrong, I'm not arguing that faster clock speed or richer instruction set would not benefit the controller. I just find nonsense to have a physical controller and transform it into a dumb thing that only understand a stream of pulses thus moving all the complexity to the application layer running on a non RTOS kernel. People are moving to Octoprint and lookalikes because it's easier to click "print" instead of swapping SD cards.

We shall not go into the consumer CNC world direction: EMC2, parallel ports, RTOS issues and dumb controllers.

[thawkins]

It does not work like that, the PC end does all the coordinate to step translation and prepares and checks the gcode, breaking it down into a simpler set of instructions that are based on steps not mm. It's not doing anything that needs an rtos, it's doing stream transformation. The firmware does not need to validate the action primitives coming down the wire.

You could actually do this by having everything up to the segment buffer in the PC, then have a dozen or so "opcodes" that would go to the printer, be queued and then executed. No PC side rtos is needed. On fact the downstream from the segment buffer and the ISR is the only thing that needs to run in the controller. There will be a bunch of functions for doing things like, home, set temps etc but it's all pretty low level. That's essentially how Sailfish works, at its basic level. Acceleration etc is handled at the firmware end. On Feb 27, 2016 8:39 PM, "João Brázio" notifications@github.com wrote:

Don't get me wrong, I'm not arguing that faster clock speed or richer instruction set would not benefit the controller. I just find nonsense to have a physical controller and transform it into a dumb thing that only understand a stream of pulses thus moving all the complexity to the application layer running on a non RTOS kernel. People are moving to octoprint and lookalikes because it's easier to click "print" instead of swapping SD cards.

We shall not go into the consumer CNC world direction: EMC2, parallel ports, RTOS issues and dumb controllers.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2051#issuecomment-189630310 .

[TBSliver]

the 1280 has worked for 3d printers with Marlin before, admittedly quite a while ago, and was replaced by the 2560. However to simplify things it may be worth just concentrating on one of them at a time.

As for the speed thing, I have recently got to the stage of printing things with the Makerbot i was working on - I ended up putting in a Smoothieboard as its the only thing that supported the dual thermocouple out of the box. However, when trying to run a Makerbot Replicator 2x clone at above 50mm/s it shakes so much it isn't feasible to print above that speed.

Obviously when trying to use a Mightyboard with something like a delta style printer, those sort of speeds (under 50mm/s) are easily achievable, however with a Delta I would probably be looking at a more mainstream board. (Although, as I'm currently building a delta, i was probably going to put a basic Ramps or Sanguinololu in it to begin with just because they're quite cheap!).

All that said, I do now have access to a Mightyboard not connected to a printer, so may be able to do some investigatory development with it instead of totalling my friends printer... (assuming I find more free time to do such a thing)

[thawkins]

I have a flashforge creator pro, which is 2560 Mighty Board based machine which is a clone of the Makerbot 1 Duo. My normal printspeed on that hardware is 60mm/s on ABS and about 80mm/s on PLA. I have had it running quite happily at 90-100 mm/s without too much trouble. The issue at higher speeds was corner ringing, some of which can be reduced by taking out one of the motors and extruders (they just unplug, after removing two bolts).

The only reason why I don't run at 90mm/s is that I get a higher number of jams when going that fast, and with ABS, you need to wind the temp up to about 245-250 to make the melt fluid enough to extrude at that speed. However the stock ff has ptfe lined extruders, so it does not like operating at that temp for too long.

I have a set of all metal extruders I'm getting up the courage to fit, and I expect to be able to hit 90mm/s printspeed with those fitted. On Feb 27, 2016 10:18 PM, "Tom Bloor" notifications@github.com wrote:

the 1280 has worked for 3d printers with Marlin before, admittedly quite a while ago, and was replaced by the 2560. However to simplify things it may be worth just concentrating on one of them at a time.

As for the speed thing, I have recently got to the stage of printing things with the Makerbot i was working on - I ended up putting in a Smoothieboard as its the only thing that supported the dual thermocouple out of the box. However, when trying to run a Makerbot Replicator 2x clone at above 50mm/s it shakes so much it isn't feasible to print above that speed.

Obviously when trying to use a Mightyboard with something like a delta style printer, those sort of speeds (under 50mm/s) are easily achievable, however with a Delta I would probably be looking at a more mainstream board. (Although, as I'm currently building a delta, i was probably going to put a basic Ramps or Sanguinololu in it to begin with just because they're quite cheap!).

All that said, I do now have access to a Mightyboard not connected to a printer, so may be able to do some investigatory development with it instead of totalling my friends printer... (assuming I find more free time to do such a thing)

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2051#issuecomment-189648059 .

[jbrazio]

So.. the limiting factor in your setup is not the firmware but the hardware.. I wonder who wrote that a few comment before. ;-)

[thinkyhead]

flashforge with a 2560 mighty board in it, I may be interested in getting it working in Marlin.

Our first aim – purely practical — to get Marlin up and running on a MightyBoard, able to control steppers (including micro-stepping), set temperatures, read sensors…. We need to start a pins file, based on something definitive. This Sailfish MightyBoard 2 Config Header contains some pins definitions. I admit I'm naive on translating pin numbers, so if anyone knows how to make a Marlin pins_MIGHTYBOARD.h file out of it, the world would be most grateful!

Having said that sailfish is remarkably capable, and sets a very very high bar.

There is some effort afoot to improve the interface experience with Marlin, which is constantly being customized by vendors. They add graphical menus, step-by-step wizards for setup and bed leveling, custom boot screens, and other tweaks. (See M600 by @josefprusa in his stripped-down no-frills Marlin, for example.) We should include more reference code to demonstrate these kinds of customizations, perhaps make better hooks for the purpose.

The performance of Marlin's stepper routines is pretty good. The stepper code hasn't changed much since Sprinter. It's probably worth going through it and seeing where we can optimize. As far as I know anything that can be called from the main loop() or idle() functions has already been removed from the ISR, but I haven't looked at the code in a little while.

…S3G… the PC side driver has to know about the steps/mm as it does all the conversions…

The code could be reworked to handle alternative dialects. It would be nice to separate the planner-injector part of Marlin from stepper block queue and the rest, then we could have more options to control the machine using different dialects. But the GCode parser in Marlin is pretty pervasive right now. Each handler function actually reaches into the GCode command string for the values it needs, scanning the whole string once for its parameters, so the command scanner is pretty inefficient. Compare Marlin's parser to the FiveD GCode Interpreter included with RepRap Firmware, or the Repetier GCode Parser and you can see that Marlin needs a lot of work. First we need to de-couple commands from the input dialect, and then we need to make a mid-level API that takes steps instead of mm. Note that Marlin only works with millimeter units currently.

[jbrazio]

Thank you for your interest making Marlin better. You should re-open this topic on MarlinFirmware/MarlinDev for proper followup from the development team. We suggest you to use the MarlinFirmware/Marlin#<topic id> markdown to link back to this original topic.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.