*** Admins - I replied to a very old post that is in Archive. I’m starting this new topic to ask the same question because I’m not sure if the Archive shows current posts, so if this is not proper please accept my apologies and feel free to delete this post ***
I’ve been building 3d printers for a few years now and have gone through just about every know variant of hardware based on 8bit Atmega AVRs. I would love to port Marlin/Sailfish/Repetier or any 3d printer Arduino-based firmware to .NETMF and run it on a GHI 32bit mcu gadgeteer board. Has anyone done any heavy lifting in porting grbl or any CNC/3d printing control to .NETMF?
That’s going to be quite a challenge. Pauses for GC will not be good for 3D printing. Wouldn’t be so bad for a regular CNC but for a 3D printer pauses = blobs. I don’t think anyone’s been crazy enough to take it on yet. I’ll be ready to plug in your firmware and give it a go when you’re ready. Good luck!
What driver hardware do you have in mind? Perhaps one of the newer RAMPS variants will work with the Cerbuino.
That’s the question… I sometimes see tiny pauses even on my Arduino based controllers and its very obvious in the prints. Most of the current controllers are pre-calculating several steps ahead of where they are currently printing so they can determine acceleration, etc. They’re also streaming data back to displays, web proxies, etc. It’s certainly possible to make it deterministic but it’ll be quite a challenge. My hat’s off to him if he puts in the effort to get it all working.
Yes I was thinking that the “quickest speed to market” would be to interface with a RAMPS board for the I/O. But I could also see a near term future of rolling a new board altogether - the boards are pretty simple.
For sure the bigger challenge is the firmware. The GC impact is a good point, and i was also worried about threading prioritization concerns. Perhaps if i go with a fast enough board, those types of issues would be moot (Hydra or Raptor??).
The other consideration is to maybe put the look-ahead logic and other time sensitive routines into RLPs. Unfortunately i’m proficient enough to read C and generally port to .net, but am not comfortable writing C or assembly. Challenges, challenges…
I did find a few projects on github where folks have created grbl UIs, so perhaps the g-code reading and machine control stuff wont be too bad. But the 3dprinting unique functions is daunting.
@ dekes1 - If you are timing your stepper motors manually (i.e. with code) then using .netmf = fail. Off load it to a dedicated Arduino (or simmilar) and let .netmf be the supervisor for it. Trig on netmf ain’t hard. Or you can offload it to an integrated driver like the l6470 (one per axis).
Interesting read on the L6470 (and 6472). I was not familiar with that chip. It looks like it manages all step timing internally and only requires position/accell/deccell to be passed over SPI. Much nicer than manually counting and managing steps in code. There’s also already a branch of the Marlin firmware that has rudimentary support for the L6470 built. Ripe for porting.
But what is your concern with managing steps in netmf? I understand the overhead the framework adds to processing speed, but when we’re talking a 240 to 400Mhz processor versus a 16mhz Arduino, I assume it would not be a problem. Worst case, the printer may not be able to support faster print speeds than what is currently the upper end - am I missing a key concern?
[quote=“dekes1”]But what is your concern with managing steps in netmf? I understand the overhead the framework adds to processing speed, but when we’re talking a 240 to 400Mhz processor versus a 16mhz Arduino, I assume it would not be a problem. Worst case, the printer may not be able to support faster print speeds than what is currently the upper end - am I missing a key concern?
[/quote]
I think the main concern here is around the managed environment of NETMF. Regardless of what your processor speed is, each thread is still going to be divided into 20ms slices. That could be a problem for realtime operations such as this if you are using multiple threads or are doing things that would trigger the garbage collector.
I’ve been reading more about the L6470 and one repeated theme is that it’s difficult to synch across multiple chips. Since the axes movement must be spot-on synchronized, small offsets in timing would result in failed segments. Most printers will require 4 chips to be synchronized at minimum (with some requiring up to 6 axes). The datasheet and the Sparkfun example code show how to use the first chip in a series as the master clock from which all subsequent chips derive timing, but it’s reported that this can still be problematic.
One of the other concerns is that the chips are a bit pricey at about 12 bucks a pop. Multiply that by 6 axes and it results in a printer board (plus a GHI mcu board) at a price point way above any existing boards or even the recent 32bit boards like Smoothieboard.
I think I’m going to try the slow way of managing step timing manually in code and see what I can do to alleviate GC issues. But I did order a few of the 6470 breakout boards to play with anyway :
I read a lot about the claim that .net because it is managed and uses a gc is not suitable for “real-time” controlling devices. But what is “real-time”? I think I would not build an oscilliscope or comparable from general-purpose hardware, be it Arduino or NetMF, because of the MHz requirements in the timescale. A 3D printer prints what,1 cm/s? The filament width is 0.3 mm? This would mean that if the timing is off by a lets say 1 milliseconds this would lead to 0.03 mm? a tenth of a filament thicknes, about 10% error? Is this really a problem?
In Internet traffic, video streaming and all other com based resources there is a transition between managed and unmanaged code. In these cases, timing never is an issue. Not even in video streaming. Why in 3D printing?
On PC’s there is not a noticeable delay for the GC. Because it is handed off to a thread other than the main thread. CPU’s used in embedded programming have but one core?
Can someone help me understand the root-cause of the NetMF timing problem?
[quote=“Chakotay”]
I read a lot about the claim that .net because it is managed and uses a gc is not suitable for “real-time” controlling devices. But what is “real-time”? I think I would not build an oscilliscope or comparable from general-purpose hardware, be it Arduino or NetMF, because of the MHz requirements in the timescale. A 3D printer prints what,1 cm/s? The filament width is 0.3 mm? This would mean that if the timing is off by a lets say 1 milliseconds this would lead to 0.03 mm? a tenth of a filament thicknes, about 10% error? Is this really a problem? [/quote]
Of course, it all depends on your needs. Most people working on 3D printers are spending most of their development time trying to figure out how to make them go faster and with higher accuracy. Would you start off a project where high-speed and high-accuracy are the goal with a component that is slower and produces a 10% error (your words)? It might not be a problem if you’re OK with slower prints but 3D printing is already far too slow with the fastest of components. I realize that most of that slowness really isn’t related to the processor… So, I encourage you to tackle it if you want to do it as a research project. I don’t see it as a viable commercial or even a widely accepted open source project. This could all change, though, once we have the AOT compiler for NETMF. So, results you see now could be remedied by compiler upgrades in the near future.
Yup. All of the current NETMF microcontrollers only have a single core and their processing power dwarfs in comparison to that of your PC.
I still think you need to prove that there is a “problem”. The risk is that because NETMF is managed and uses a garbage collector, you will get random 100ms (or longer) pauses when the micro needs to free up some memory. Pauses = blobs in 3D printing. You should do some tests using a working 3D printer and modify your GCode to insert some random 100ms pauses in the print. I’d be curious to see if its noticeable. If they were truly random and didn’t align in the print then it may not be noticeable at all. You’ll just have to do some tests and see if that’s acceptable for your needs. And if all you are going to do are the basic motions for the printer then you very well could write code that cause none or very little GC. However, if you decide to add other features requiring networking, displays, etc. then the difficulty in keeping the GC to minimum gets exponentially harder.
I don’t want to discourage you. I’d love to see you tackle it if for no other reason than to prove it works or it doesn’t.
ok, thanks for the headsup. My goal was to improve on the Arduino based motherboard of my 3D printer. I hoped to improve on the reliability of the print process, like automatic calibrating z-axis, automatic changes of filament, faster diagnosing of problems etc, Not necessarily on speed but I still hoped for an improvement on that too, as fast would be nice.
Where do the blobs come from? My understanding is that if the motor of the filament stops, no filament will come out. Is it the case that when the CPU stops, the motors keep on going?
My understanding is that VS compiles my C# into IL. At first execution the IL gets compiled (“automagically”) into native code (JIT compiled), I might also do this by hand. Based on that assumption after the initial load the performance should be the same. Reading up on your remarks about the AOT compiler I see that on NetMF the IL gets interpreted? Is this correct? Wow, disappointment. My knowledge in the PC world is not as portable as I hoped for. see also: A different approach to speeding up managed code - General Discussion - Netduino Forums
Are there any plans on AOT or JIT compilers for ARM?
I think I will try to see how far I come. Maybe technology catches up.
You have to remember that you’re dealing with a molten plastic. Even when the motors stop the plastic will still ooze out. Under normal circumstances when pauses can be predicted, then the printer software will issue a retract to suck the plastic back up into the printer head and prevent ooze. However, in this case when the GC will be unpredictable this isn’t an option. Similar type of problems can be seen with the Arduino based boards when the motor driver skips a step due to overheating or if the CPU gets behind.
Correct. Due to limited resources on the early micros it was actually found to be faster to interpret on demand rather than JIT (and keep the compiled binary in memory). Microsoft has said they are introducing AOT in “the next major release of NETMF”. Not sure what or when that means but I trust that its coming.
I think I will try to see how far I come. Maybe technology catches up.
[/quote]
@ ianlee74 - I really think GC can be predictable. The inner loops that handle critical tasks can be coded so it does not allocate any object, and so not running the GC.
Afterall, the GC will only run for one single reason and no other, memory is needed and no free blocks are found.
Ok, so if I do not allocate any new objects during print I should be fine. Will keep that in mind.
Thanks guys, so far.
The threading issue is also interesting: is it under NetMF possible to choose STA instead of MTA which is (obvious?) the default? To avoid the problem of my threads being chopped up in 20ms portions?
Does NetMF have a concept of asynch? My fantasy tells me that if I have a driver board, like L6470, with its own chip I should be able to offload some work to that core and let the CPU do other stuff? Like adjusting temperature and watching for endstops?
The other solution would be to check temperature and endstops after every motor-step or after every direction change or something (but essentially on the main printing loop thread)? Which would result in predictable pauses?
On second thought: it all boils down to the question if there is a centralized concept of physical time on the spider? Then I can do “real time” as long as the time taken to calculate the next decision is shorter then the time forced by the physical problem domain. In this case the continuous melting of the filament.
As I said in a previous reply, I completely agree. The problem comes when he tries to add more and more features such as handling requests from a web API command, etc. which I believe he plans to implement. Then the data received and responses to those commands becomes much more unpredictable and at some point he will likely go beyond what can be predicted. But, if he takes it one step at a time and starts with the basic functions (GCode instructions) then I believe he can definitely avoid GC. It’s probably worth mentioning that these reasons are probably a large part of why current controllers don’t have these type of functions built-in and rely on something such as Octoprint on a secondary RPi or similar board.
@ Chokatay - given that it seems all of this is fairly new to you, I think my suggestion would be that you attempt a direct port of Marlin to NETMF. They’ve already worked out a lot of the issues related to the order that things need to happen, etc. to ensure a successful print. This would let you then focus on the differences between the platforms and once you get something working then you could work towards extending/improving the current capabilities.
Yes; because its a cumulative error. If the build process is 2 hours, and the system makes 1 error every 10 seconds, then the system has made 720 errors! This can cause the entire process to fail.
[quote]Where do the blobs come from? My understanding is that if the motor of the filament stops, no filament will come out. Is it the case that when the CPU stops, the motors keep on going?
[/quote]
When the filament stops the heater is still heating. A) The plastic expands when it gets hot and naturally wants to escape B) Most extruders are not gas tight, so the plastic falls out of the extruder due to gravity.
This is called “In Time” as opposed to “real time”.
The L6470 can watch for ends stops for you. If you can offload watching the temp to dedicated electronics or another co-processor then do it. The last thing you want is for the system to overheat and melt the thermal barrier (or ignite).
If you really need some time critical functions then switch those functions to GHI’s RLP; keep them small and efficient. Don’t put more in there then you need to (e.g. the entire Trig calculation for moving the motors), and don’t put things that can cause deadlocks (i.e. no lock statements). The L6470’s busy pin can be used as this interrupt source but I won’t tell you how.
I believe we must make a difference in these errors. The one you talk about, missed steps, is a problem in synchronized and unsynchronized scenario’s and you are right, since there is no feedback about the position of the motor this is a cumulative error and very bad. The way I understand the timing problem is that because of slicing of the threads or activity from GC the motors will get out of “sync” but this can be synched back at “natural” points like the end of a strand of filament or the end of a layer and therefore will not cumulate. There will not be missed steps because of this, at most steps are taken at unexpected (relatively spread in time) moments in time between those “natural” points.
Good temperature control should prevent the extra oozing you talk about, this must be a separate thread and causes the problems mentioned earlier. Earlier someone pointed out that the molten plastic will still ooze if not retracted. There should be no possibility of time slicing or GC pauses during print. Agree with you on that one.
Thank you for the correction.
My question to you is: Could you please publish a link to the GHI PLR because I seem not able to find it, thank you!
Eventually I will figure out how to use the pin on the L6470 if needed, thanks!
but I won’t tell you how.