Smoothieboard 2 Progress

User avatar
626Pilot
ULTIMATE 3D JEDDI
Posts: 1684
Joined: Tue May 14, 2013 12:52 pm

Smoothieboard 2 Progress

Postby 626Pilot » Thu Dec 08, 2016 9:45 pm

This blog post was put up on November 19. There have been some big changes!

SB2 Mini design:
SB2 Mini.png

Hot end expansion boards (stepper driver + hot end power + thermistor + filament sensor), running on the CAN bus, which can be daisy-chained:
Expansion board.jpg

Highlights:

  • There is an updated SmootheBoard 1.1 with 1/32 Allegro drivers coming out in a few weeks
  • v2 will run on an LPC4337 @ 204MHz with 264K RAM (v1 had 64K) and 8MB ROM (up from 512K, I think), hardware FPU, SDIO, and an M0 co-processor
  • Smoothieboard v2 has been delayed by mbed's incomplete HAL, but they are making good headway now. They already have a prototype driving the FirePick "overhead delta" pick-and-place/3D printer. They are working on hiring full-time developers to finish the port, and to work on an RTOS port in the future
  • SB v2 will come in regular, Pro, and Mini trims
  • v2 Mini will be as cheap as possible and have 4 of either either Allegro or Hero drivers, and you'll have to solder the connectors yourself; also only one hot end FET and one SSR/Servo connector, 3 endstop+1 probe connectors, no multi-extruder CAN, extra USB port (thumb drive), and no Ethernet
  • v2 (regular) will have 4 Trinamic stepper drivers, 1 bed FET, 2 hot end FETs, 2 SSR/Servo connectors, 6 endstop+1 probe connectors, multi-extruder CAN (see below), extra USB port, and Ethernet
  • v2 Pro will have 5 Trinamic stepper drivers, an FPGA, 2 bed FETs (why?), 2 hot end FETs, 4 SSR/Servo connectors, 6 endstop+1 probe connectors, one DAC, multi-extruder CAN, extra USB port, and Ethernet
  • The problematic Molex power connectors (just replaced a melted one two days ago) are being replaced with XC30/XC60 connectors, like you see on RC applications like drones - big cheers from me on this decision
  • Edison port dropped (good choice, in my opinion)
  • Gadgeteer-compatible expansion ports added - you can use these to connect an Edison, Raspberry Pi, extra stepper driver boards (planned), cameras, sensors, LCDs, or whatever - this is like having a GPIO header, except much more flexible, as each connected device gets its own port (you don't have to figure out how to split them up or use a custom PCB to break out the wires). The v2 Mini has six of these ports, and the regular and Pro boards should have "as many as possible"
  • Stepper expansion boards will run on a CAN bus (like in your car) with an extra STEP signal, can by daisy-chained to have "infinite" drivers, and use the same XC-type power connector (each has In and Out connectors). Each board has a stepper driver, "hot end" (presumably power FET + thermistor input), and a filament sensor, which is legit as hell. The boards are being developed by Kliment (author of Pronterface) and appear to have their own onboard CPUs, which makes sense, because they have to talk to the CAN bus and send/receive/forward serial data
  • JTAG port (unsoldered) for debugging
  • They want to hire Thomas Sanlander, famous hardware reviewer for YouTube, to do tutorial videos
I think it was a good idea to drop the Edison socket, and a better idea to add the Gadgeteer interfaces. All an Edison (or RasPi) really needs to talk to the controller is a serial line of some kind, like CAN, I2C, or SPI. It doesn't need 40 or 80 pins just for that. Because each Gadgeteer interface stands alone, there is never a question of where to plug something in, or whether it has to have custom jumper wires running to a pin here and another pin there.

This really does seem to be shaping up to be the Cadillac of 3D printing controllers, and I am DEFINITELY getting one as soon as I can! This is doubly great for me because I was thinking about developing my own CAN-based, daisy-chainable solution for running extra hot ends. Now I don't have to!
Last edited by 626Pilot on Sun Dec 11, 2016 1:14 am, edited 1 time in total.

User avatar
mhackney
ULTIMATE 3D JEDDI
Posts: 5327
Joined: Mon Mar 26, 2012 4:15 pm
Location: MA, USA
Contact:

Re: Smoothieboard 2 Progress

Postby mhackney » Fri Dec 09, 2016 9:03 am

The hardware controller is, in my opinion, the least important part as long as it meets requirements and is robust. The firmware is the important thing since that is what users (and novice users) interact with on a daily basis). Currently, the dc42 firmware and Duet Web Control interface are the gold standard in that area. Smoothie has work going on to implement a real web interface but it still does segmented delta moves and it's native delta calibration is more primitive. There is a fork of smoothie with David's calibration but that has its own little issues (I can't run the LCD at the same time for instance). And the LCD support is similarly primitive compared to Duet and PanelDue. Again, these things can be addressed but they are at least a year away and likely longer.

Now that I've been using the Duet/dc42 for over a year, all future boards and firmware plus control UIs (panels and web interfaces) are going to have to offer something significant above that. It is a thing of beauty to set up my delta at a presentation, warm up the bed and hotend (about 90 seconds), press calibrate (25 seconds) and print, all from my iPhone.

It will be good to have several options, competition is good. I don't think there needs to be one outright winner, there never is in technology. There will be Duet camps and Smoothie camps. I intend to continue to monitor smoothie and I'll likely get the v2 when it's available but it would take some amazing advances in firmware and UI to convince me to migrate.

Sublime Layers - my blog on Musings and Experiments in 3D Printing Technology and Art

Start Here:
A Strategy for Successful (and Great) Prints

Strategies for Resolving Print Artifacts

The Eclectic Angler

User avatar
626Pilot
ULTIMATE 3D JEDDI
Posts: 1684
Joined: Tue May 14, 2013 12:52 pm

Re: Smoothieboard 2 Progress

Postby 626Pilot » Fri Dec 09, 2016 7:29 pm

I would have gone with a MCU that had a lot more memory, but I guess they don't think it's super important. They may have settled on that back when they were sure the thing was going to be running the front end interface on an Edison.

Smoothie's edge release is doing instantaneous step generation. As I've said before, I can't tell the difference between 1KHz and continuous updates. I guess people who use that slicer that generates movements smaller than a blood cell will rejoice. I think it's supposed to be more tolerant of that kind of ridiculous G-code.

There is a Smoothie feature to add PanelDue support. That is definitely head and shoulders above Smoothie's current web interface. Maybe with that bigger ROM, they can burn in a few images and some CSS, and make the interface look better than it does now. My preference is to use a RasPi + WaveShare LCD, which costs about the same as a PanelDue. The OctoPrint interface is very good, supports live streaming and time lapse; and thanks to the Pi's expansive RAM, it will let me upload a 25MB G-code file in a few seconds. You just get more features using the Pi. It is definitely nice to be able to check on the print, shut down the heaters, etc. from another room on my cell phone, and I think the time lapse capability could have some commercial potential.

The Gadgeteer interface gets my attention because it may provide a better serial interface than USB, and because it's a welcome departure from either having custom pins for custom things (PanelDue) or a monolithic expansion header. I have had prints stall a couple of times, and I'm not sure why (possibly EMI). This is out of hundreds of hours, but it still bugs me. If doing serial over the Gadgeteer interface can be more reliable than USB, maybe I don't have to have that happen again. The cables are flat, and can be very short. That makes them easier to route in tight quarters than a round USB cable that can't bend as easily as a flat cable.

Smoothie's current delta calibration support is supposed to be "good," better than it was a year ago. They have Z-only correction available in the main firmware as well. I haven't tried it, so I don't know how well it would work on my machine, or how easily. My own Smoothie fork has been giving me calibrations with a standard deviation around 40-45 microns - this is using printed magnetic carriages and effectors, and the ball joints are not perfectly height-calibrated (working on a tool to level them) so they are not at identical heights relative to the effector/carriage bases. Other people have got calibrations around 20 microns, which is equivalent to two or three steps, depending on the resolution of the motors. If I try Smoothie 2 and the calibration isn't as good, I might look into porting my calibration system to it. If nothing else, my firmware produces human-readable depth maps of the bed, so you can really see what you're getting.

arthurwolf
Prints-a-lot
Posts: 21
Joined: Sat May 24, 2014 3:36 pm

Re: Smoothieboard 2 Progress

Postby arthurwolf » Sat Dec 10, 2016 6:12 am

Hey everybody, Arthur from the Smoothie project here, with a few comments :)

First on the spec, 626Pilot has most things right, except the RAM/Flash : Smoothieboard v2 will have 264kB of RAM, and 8MB of Flash ( I think the values you posted are older ones ).
That's 200kB more RAM than what we have now, which should give us a lot of freedom moving forward. We are getting a much better network stack, a longer planning queue with more information stored into it, a RTOS, and all sorts of other goodies like that.

The RTOS we plan on using is NuttX ( nuttx.org ), if you go look at it's features you'll see lots of exiting things.

About mhackney's comments on the web interface, we are very much aware that the current one sucks.
You can install better interfaces contributed by the community here : http://smoothieware.org/install-web-interface ( essentially storing the interface on the SD card instead of flash so there is no space limit ) however they are still not as good as RRF's interface.
However, we are working on making Smoothieware compatible with both the PanelDue and RRF's web interface, after which you'll be able to use both out of the box with Smoothie. That work has been going on for months and is nearly complete ( you can even test it if you want by compiling the adequate branch ).
On top of that, we are working on a really awesome interface project called fabrica, you can take a look at the idea here : https://docs.google.com/document/d/1YaL ... ne0og04bp5
The project has so much potential that 4 companies ( Uberclock, Robotseed, Panucatt and Openbuilds, with others still negotiating ), have come together to finance the project monthly for the year to come, to pay contributors for implementing specific things in it. So look forward for fast progress there.

About the no-segments delta stuff, while it might sound better to not segment, in practice, users have looked into it, and for various reason, there is no difference in the end result ( steps generated ) between segmenting ( at high rates like smoothie does ) and not segmenting ( like duet does ). Because of this we decided to not pay the price of more complex code, and lower possible maximal speed ( I don't have any figures on duet's maximum speed but I believe last time I looked it was well under Smoothie's ).
It is a very interesting experiment though and I'm glad somebody tried it. Maybe as we move forward and have more complex usecases for our machines somebody will find a system in which doing the segmentless approach does bring something to the table, in which case we'll definitely look into adding it.
But there's no point if it doesn't have any benefits at the moment.

On calibration, Smoothie now has both "normal" delta calibration, and grid-based leveling, which does the job perfectly, even on very large machines. I think this is again an example of trying something cool but ultimately not needed.
I know it feels great to know your machine is doing something more complex than your neighboors, but ultimately, the Smothie project will always choose to work on whatever brings the most tangible benefits to it's users, and as far as we can see, right now, that's not the fancier delta calibration stuff, as the one we have now, coupled with grid levelling, essentially brings perfect results.
Again if machines progress to the point where that's not true anymore, we'll definitely look into it again. We'll definitely have the room to do it in v2.

Both on segmentless delta and more complex calibration, I want to say that these are things we looked into *a lot*, and decided not to go through with because of the lack of actual improvement. But again it's great that somebody has tried them, and I think RRF is slowly positionning themselves as the guys who try that sort of crazy stuff so that others can know if it's worth adding or not :)

Smoothie has been around for 4 years now, it's got a large community, a very neat codebase, the best documentation around, and it has brought the comumnity a lot of things that didn't exist before ( and quite a few of those are to this day still only found in Smoothie ). With v2 we are working towards doing the same thing we did 4 years ago : do a lot of things that nobody has done before, and bring a big step forward to OpenSource CNC controllers.

One thing that might come with Smoothie2 that is interresting here, is the ability to compile module as standalone files, and have them loaded by Smoothie at runtime. What this means is that one could create their crazy new delta calibration thing, and just distribute it as a file that people can add to their SD card to try it. This solves the problem we have now where the Smoothie devs have been refusing some features in the main code because they do not know that new code well enough to guarantee they can maintain it in the future. This means you are much more likely to see those crazy features come easier into Smoothie in the future ( that and the large increase in RAM and Flash )

Cheers :)

Mac The Knife
ULTIMATE 3D JEDDI
Posts: 1227
Joined: Sun May 11, 2014 6:18 pm
Location: Lansing, MI

Re: Smoothieboard 2 Progress

Postby Mac The Knife » Sat Dec 10, 2016 7:56 am

Would someone explain what you mean by "segmentless delta"? I'm understanding it as the ability of the controller to accept a G2, or G3 command. I was given the impression that it wasn't implemented, in general, because very few slicing programs were implementing "arc fitting" to generate G2/G3 codes.

arthurwolf
Prints-a-lot
Posts: 21
Joined: Sat May 24, 2014 3:36 pm

Re: Smoothieboard 2 Progress

Postby arthurwolf » Sat Dec 10, 2016 8:04 am

Mac The Knife wrote:Would someone explain what you mean by "segmentless delta"? I'm understanding it as the ability of the controller to accept a G2, or G3 command. I was given the impression that it wasn't implemented, in general, because very few slicing programs were implementing "arc fitting" to generate G2/G3 codes.


Hey !

G2/G3 is implemented in Smoothie, this is executed by segmenting the arc into many small segments, and executing them in turn.

What we are talking here however is different. On delta printers, movements ( from the actuator point of view ) are not linear. The delta math makes it so they are not straight lines, but complex curves the actuators have to execute.
In Smoothie, this is handled much the same way as G2/G3 : the movements are cut into many small segments and executed in turn.

On the Duet boards however, this is implemented by actually executing the arcs by doing the math for each step, they do not cut the movements into segments but execute the whole movement by doing the math "on the fly" ( while Smoothie does the math in the Planning phase, on the segments it cut ).

What I was talking about is the fact that if your segments are small enough ( most moves in Smoothie on a delta are only one or two steps long at high speeds ), there is essentially no detectable difference between the two methods. And because doing the math "on the fly" is much more expensive computationally than doing it in advance, we chose to use the segmentation method.

Hope this makes it clearer.

Mac The Knife
ULTIMATE 3D JEDDI
Posts: 1227
Joined: Sun May 11, 2014 6:18 pm
Location: Lansing, MI

Re: Smoothieboard 2 Progress

Postby Mac The Knife » Sat Dec 10, 2016 8:14 am

Thanks, I had assumed that was what it was, since it was referenced as "segmentless delta". Also, the mechanical bits of most deltas are going to smooth out most of the movements anyways.

arthurwolf
Prints-a-lot
Posts: 21
Joined: Sat May 24, 2014 3:36 pm

Re: Smoothieboard 2 Progress

Postby arthurwolf » Sat Dec 10, 2016 8:35 am

Mac The Knife wrote:Thanks, I had assumed that was what it was, since it was referenced as "segmentless delta". Also, the mechanical bits of most deltas are going to smooth out most of the movements anyways.


Well some people do have extremely well built deltas where this question matters, but what I said applies even there.
On most deltas though yes even if there was a difference, it wouldn't really show up.

dc42
Printmaster!
Posts: 224
Joined: Mon Mar 07, 2016 10:17 am

Re: Smoothieboard 2 Progress

Postby dc42 » Sat Dec 10, 2016 4:16 pm

1. Regarding the segmented/segmentless delta motion, people tend to concentrate on the error at the centre of a segment, which is tiny if the segments are short enough. However, the other factor involved is that at the boundary between segments, the head position has to be rounded to a whole number of microsteps for each motor. So you get a small discontinuity at each segment boundary. Whether this makes any difference I can't say, because until very recently RRF has no facility for segmenting moves, so I haven't been able to do a comparison. My main motivations for implementing segmentless delta motion were (a) segmentation for delta motion is a hack (I believe Johan Rocholl said as much after he implemented it in Marlin), and (b) I like to reduce the support I need to give to users as much as possible, and explaining the delta segments-per-second parameter to a naïve user is something I prefer not to have to do.

2. Regarding the Smoothie 2 announcement, I'm glad to see that Smoothie 2 has made progress. Competition is good for the industry. On the particular features:

- CAN bus peripherals is interesting, because it's something we had already decided to implement in Duet WiFi 2 (we looked at RS485 too, but CAN is simpler because so many microcontrollers support it directly). Great minds etc. I don't think we will be using it for driving additional stepper motors though. You still need either a separate step signal (as on Smoothie) or a "start move" sync signal. Also you have to be able to send details of the next move over CAN before it starts, so that the drivers know at which step to switch the direction signal. This must surely limit the moves/second, although I haven't yet done the sums to see what rate would be achievable. With Duet WiFi + Duet X5 we support 10 drivers, and nobody has asked for more yet. If someone does need more than 10 independently-controlled drivers, I guess Smoothieboard will win for that user. For other users, I think cost will be an important factor, e.g. is there a significant price difference between a Duet WiFi + DueX2 or DueX5 on the one hand, and a Smoothieboard 2 + additional stepper motor modules on the other?

- Processor: Smoothie 2 is getting a much more powerful processor than even the Duet WiFi has. We're also planning a processor upgrade for Duet WiFi 2. However, the Duet WiFi processor is quite powerful enough at present, and we still have quite a lot of spare RAM - so no problems switching to a RTOS. It helps that all of the TCP/IP stack and much of the web interface is offloaded on to a separate processor. But even the Duet 0.8.5 with just 96K of RAM manages a good TCP/IP stack and web interface without a coprocessor, and we can quite easily reduce the RAM requirement of the planner if we need to. It helps that we code to high-integrity standards (my background is verification of high-integrity embedded software), which means no dynamic memory allocation after the initialisation phase - hence no memory fragmentation, and the memory requirement/free memory is pretty much known after initialisation is complete.

- Gadegteer interface: interesting, and something we hadn't considered. Will watch to see how it works out. There do seem to be a lot of different Gadgeteer socket types, and I wonder how many of them Smoothieboard 2 will support. IMO CAN is much more flexible, but Gadgeteer allows "dumb" (and therefore cheaper) devices whereas CAN doesn't.

User avatar
626Pilot
ULTIMATE 3D JEDDI
Posts: 1684
Joined: Tue May 14, 2013 12:52 pm

Re: Smoothieboard 2 Progress

Postby 626Pilot » Sun Dec 11, 2016 12:59 am

I guess I was mistaken about segmentless calculations being in Smoothie edge. I don't remember where I read about that. I suppose it was just in a testing branch. Sorry about that.

Their CAN implementation has an extra differential STEP line. The bus can run at either 1 or 8 Mbit/sec, depending on which controller they use. Even at 1Mbit, the math isn't too bad. The frame size (if you want to send 8 bytes) is 108 bits (13.5 bytes). That gets you a destination address and CRC for error correction, and the protocol handles error correction (resend) and congestion for you. At 1MBit, you can send 9259.259259... frames per second. Enough to run 8 external steppers at 1KHz update speed if they use all 8 bytes to tell them what to do. If the data they send is a 32-bit packed dir/float (1 bit dir, 31 bits step frequency) then they can run 16 external steppers. If they can get away with a 15-bit frequency, that means 32 steppers. That begins to get into android-type robot territory, similar to using DynaMixels but possibly cheaper per unit of torque delivered.

In fact, that gets me thinking...

Because each stepper expansion board has its own controller, it would also be possible to send the mathematical description of the required movement (line or Bezier curve) to each controller, and then let it generate steps locally. If someone develops a general robotics expansion board for Smoothie 2 - no printer stuff like hot end heat, but an encoder input, perhaps IMU (accelerometer/gyro/magnetometer) and some kind of torque sensor as well - the board can probably be made small enough that you could integrate it and an encoder with a stepper, and it can send the IMU/torque readings back to the Smoothie controller, which can supply it to whatever application is driving the robot. That would help the controller keep the robot balanced, if it's the kind that needs to walk, and help it avoid breaking eggs or damaging its own joints. With that method (sending a definition of the curve rather than every individual step), the CAN bus could drive several dozen motors without running out of bandwidth on the bus, and have plenty left over for IMU/torque feedback. Since they already have a separate STEP line, the different controllers can be kept in sync, maybe with a PLL in case there is any tiny drift in clock speed between the expansion boards. This feature could make the SB2 Pro very attractive to people who want to develop quadrupedal, humanoid, or other robots with highly complex articulation. (Wonder if they thought of that?)

dc42
Printmaster!
Posts: 224
Joined: Mon Mar 07, 2016 10:17 am

Re: Smoothieboard 2 Progress

Postby dc42 » Sun Dec 11, 2016 3:20 am

Instead of a differential Step line, I would look at using use a differential Start Move line. Then the same signal can feed all the expansion boards. Each expansion board would already have the move details when Start Move goes active. In RRF they would be segmentless delta moves with acceleration and deceleration, and Cartesian moves with pressure advance option. This does increase the amount of move data that needs to be sent in the CAN packet, so I would need to check whether a sufficient rate is sill achievable when printing curves as sequences of short segments.

Some special action would be needed to handle homing and Z probing moves, where it is sometimes necessary to stop several motors simultaneously. The Start Move signal could be used for this too.

gchristopher
Printmaster!
Posts: 136
Joined: Mon Dec 08, 2014 2:09 am

Re: Smoothieboard 2 Progress

Postby gchristopher » Fri Dec 16, 2016 8:26 pm

I'm still running the original RAMBo and would be interested in the Smoothie 2. I like the idea of having the firmware codebase be non-Arduino, so it'd be nice to see the Smoothie catch up to the Duet in features and usability.

dc42
Printmaster!
Posts: 224
Joined: Mon Mar 07, 2016 10:17 am

Re: Smoothieboard 2 Progress

Postby dc42 » Sun Dec 18, 2016 3:43 am

gchristopher wrote:I'm still running the original RAMBo and would be interested in the Smoothie 2. I like the idea of having the firmware codebase be non-Arduino, so it'd be nice to see the Smoothie catch up to the Duet in features and usability.

FYI RepRapFirmware has also been non-Arduino for the last year.

arthurwolf
Prints-a-lot
Posts: 21
Joined: Sat May 24, 2014 3:36 pm

Re: Smoothieboard 2 Progress

Postby arthurwolf » Sat Dec 24, 2016 4:39 pm

dc42 wrote:1. Regarding the segmented/segmentless delta motion, people tend to concentrate on the error at the centre of a segment, which is tiny if the segments are short enough. However, the other factor involved is that at the boundary between segments, the head position has to be rounded to a whole number of microsteps for each motor. So you get a small discontinuity at each segment boundary. Whether this makes any difference I can't say,


That's actually been measured ( months ago, I'd have a hard time documenting this ), both by Smoothie devs, and users who own both boards running RRF and Smoothie, and it was found that the difference between segmenting and not was essentially ( with the current firmwares/hardware ) so small it was drowned into the inacuracies you get just from using microstepping. That's both from accurate measurements, and from user "feeling"/print results.

So we chose to keep our higher 100khz step frequency rather than exploring segmentless step generation. However if somebody is able to show an advantage to segmentless step generation we'd definitely look into adding it.
It's really cool you actually tried it though, it must not have been easy.

Really it's all about placing the cursor somewhere. We could have a max step frequency higher than 100khz if we did our acceleration less properly, or have it lower if we had S-curve acceleration. You have to choose a good compromise, and this is our current one, and users seem fairly happy with it ( machines that require more than 100khz are still rare, and users really like the better planning/accel we've gotten over the years ).

dc42 wrote: because until very recently RRF has no facility for segmenting moves, so I haven't been able to do a comparison. My main motivations for implementing segmentless delta motion were (a) segmentation for delta motion is a hack (I believe Johan Rocholl said as much after he implemented it in Marlin),


Well, lots of what we all do is a hack ...
We used segmentation both for delta motion and for arc motion, because it's simpler to implement, and more efficient.
It's definitely possible to mess it up ( which Marlin does on some fronts ), but if done correctly ( which we do ), it's as valid an implementation as any other. If we didn't use segmentation, some of the things we are doing now would be much more difficult, and some of the things we plan on doing later ( more complex inertial limits, S-curve step generation ) would become close to impossible.

dc42 wrote: and (b) I like to reduce the support I need to give to users as much as possible, and explaining the delta segments-per-second parameter to a naïve user is something I prefer not to have to do.


That's what documentation is for :)
Also, we don't officially support actually changing that value ( not sure why somebody would want to ), so we don't really have to explain it.

https://en.wiktionary.org/wiki/give_a_m ... a_lifetime

dc42 wrote:- CAN bus peripherals is interesting, because it's something we had already decided to implement in Duet WiFi 2 (we looked at RS485 too, but CAN is simpler because so many microcontrollers support it directly).


We are not actually doing CAN fully. It's "electrically" CAN ( with an additional step line ), but on the software side it's going to look much more like RS485.

dc42 wrote:Also you have to be able to send details of the next move over CAN before it starts, so that the drivers know at which step to switch the direction signal.


Actually, by definition ( because of acceleration ), direction changes do not happen at maximum speed, so that's very much manageable, we don't even need to send moves in advance.
It's all experimentation of course, we might run into trouble along the way :)

dc42 wrote: is there a significant price difference between a Duet WiFi + DueX2 or DueX5 on the one hand, and a Smoothieboard 2 + additional stepper motor modules on the other?


We don't have the pricing yet ( we don't work that out fully until the final design ), but it should be very reasonable, We think this is really cool, so we want people to use this :)

dc42 wrote:- Processor: Smoothie 2 is getting a much more powerful processor than even the Duet WiFi has. We're also planning a processor upgrade for Duet WiFi 2. However, the Duet WiFi processor is quite powerful enough at present, and we still have quite a lot of spare RAM - so no problems switching to a RTOS. It helps that all of the TCP/IP stack and much of the web interface is offloaded on to a separate processor. But even the Duet 0.8.5 with just 96K of RAM manages a good TCP/IP stack and web interface without a coprocessor, and we can quite easily reduce the RAM requirement of the planner if we need to


Smoothie v2 is all about experimenting with new things, and having a platform that can get us through the next few years without feeling limited in what we play with. A bit like what Smoothie v1 was a few years ago :) So yes, we did go a bit overboard with some of the specs, but I think we'll be happy about it in the future.

dc42 wrote:- Gadegteer interface: interesting, and something we hadn't considered.


How about you do it too and we make it a standard ? That'd be cool :)
We are planning *a lot* of extension boards ( https://docs.google.com/document/d/144E ... gxNM/edit# ) so if you have one of those sockets on your boards ( or more ), that opens up a lot of options for users. And users is who we all care about at the end of the day. And you can do your own extension boards too. If you have ideas for boards I'd love to hear them.

dc42 wrote:Will watch to see how it works out. There do seem to be a lot of different Gadgeteer socket types, and I wonder how many of them Smoothieboard 2 will support..


You can see what gadgeteer port types we'll have on the v2-mini : https://plus.google.com/+ArthurWolf/posts/VE3zWyTc2Ac
There'll be even more on the v2, and then more even on the v2-pro.

arthurwolf
Prints-a-lot
Posts: 21
Joined: Sat May 24, 2014 3:36 pm

Re: Smoothieboard 2 Progress

Postby arthurwolf » Sat Dec 24, 2016 4:43 pm

dc42 wrote:Instead of a differential Step line, I would look at using use a differential Start Move line. Then the same signal can feed all the expansion boards.


We plan on having the same step signal feed all the extension boards.
The faster one gets the step pulse, the other follow it at a given ratio they have been configured for.
This works both for extruder systems where only one runs at a time, and for systems where multiple extruders run concurrently but they have a fixed ratio between them. This covers all the *currently* used multiextrusion systems. It won't work for a system where ratios between the extruders vary live ( though it might ), but we'll worry about that when somebody actually builds a machine that has a use for that.

User avatar
Xenocrates
ULTIMATE 3D JEDDI
Posts: 1287
Joined: Wed Sep 23, 2015 2:55 pm

Re: Smoothieboard 2 Progress

Postby Xenocrates » Sat Dec 24, 2016 8:03 pm

arthurwolf wrote:
dc42 wrote: and (b) I like to reduce the support I need to give to users as much as possible, and explaining the delta segments-per-second parameter to a naïve user is something I prefer not to have to do.


That's what documentation is for :)
Also, we don't officially support actually changing that value ( not sure why somebody would want to ), so we don't really have to explain it.

https://en.wiktionary.org/wiki/give_a_m ... a_lifetime

As a user with a slightly more than zero understanding of industrial controls (I work with PLCs, and CNC programming), I have an honest question here. If it is unsupported to change it and there is no explanation of it, what actual documentation do you have beyond "This is a thing, don't touch it or things may explode". I don't think it's particularly helpful to have a parameter that users can change that can mess stuff up, especially with 0 explanation of it and minimal support.

arthurwolf wrote:
dc42 wrote:- CAN bus peripherals is interesting, because it's something we had already decided to implement in Duet WiFi 2 (we looked at RS485 too, but CAN is simpler because so many microcontrollers support it directly).


We are not actually doing CAN fully. It's "electrically" CAN ( with an additional step line ), but on the software side it's going to look much more like RS485.

Oh goody, something like the opensource red-headed stepchild of CAN and RS485 with DH485 as a god-father. /snark

Please, implement a single standard. If it's going to be CAN, do CAN. If it's going to be RS485, make it RS485. If for some strange reason you decide an opensource version of something like DH485 or DH+ is a good idea, go right ahead. But please don't play mix and match with standards like that. I would like to have off the shelf tools to figure out what the heck is going on in a system, and putting RS485 over CAN seems like a very cromulent approach to the problem.

arthurwolf wrote:Actually, by definition ( because of acceleration ), direction changes do not happen at maximum speed, so that's very much manageable, we don't even need to send moves in advance.
It's all experimentation of course, we might run into trouble along the way :)

It may not happen at maxiumum speed, but it will almost always happen at some level of speed. I can see a lot of potential issues if the drivers belatedly find out they were supposed to be going in the other direction, if you've got a largish jerk value and a very high step rate (Which I thought was part of the point of over-specing the processing and step generation so far.

arthurwolf wrote:Smoothie v2 is all about experimenting with new things, and having a platform that can get us through the next few years without feeling limited in what we play with. A bit like what Smoothie v1 was a few years ago :) So yes, we did go a bit overboard with some of the specs, but I think we'll be happy about it in the future.

Good on you for that. I like the idea of putting the most capable hardware you can at a reasonable price on a board, and using that to try to make sure you can continue to improve without rapid hardware (And potentially dev environment and userbase) churn

arthurwolf wrote:We plan on having the same step signal feed all the extension boards.
The faster one gets the step pulse, the other follow it at a given ratio they have been configured for.
This works both for extruder systems where only one runs at a time, and for systems where multiple extruders run concurrently but they have a fixed ratio between them. This covers all the *currently* used multiextrusion systems. It won't work for a system where ratios between the extruders vary live ( though it might ), but we'll worry about that when somebody actually builds a machine that has a use for that.


I can think of more than a few things, for example, the Mill/turn center Generic Default is building, or if you want to have your main drivers off board from the Smoothie, such as if you were using the large Gecko drivers for high torque Nema 23's or other large/high amperage/high voltage steppers.
Machines:
Rostock Max V2, 760W corsair modular PSU, PT100 enabled E3D V6 and volcano, self adjusting carriages, Raymond style enclosure
Automation Technology 60W laser cutter/engraver

Sic Transit Gloria Mundi
01-10011-11111100001

arthurwolf
Prints-a-lot
Posts: 21
Joined: Sat May 24, 2014 3:36 pm

Re: Smoothieboard 2 Progress

Postby arthurwolf » Sun Dec 25, 2016 5:21 am

Xenocrates wrote:As a user with a slightly more than zero understanding of industrial controls (I work with PLCs, and CNC programming), I have an honest question here. If it is unsupported to change it and there is no explanation of it, what actual documentation do you have beyond "This is a thing, don't touch it or things may explode". I don't think it's particularly helpful to have a parameter that users can change that can mess stuff up, especially with 0 explanation of it and minimal support.


It is documented. It's not supported to change it unless you know exactly what you are doing. We have several parameters like this, that shouldn't be changed by lambda users, but that can sometimes be useful to some users/devs.

Xenocrates wrote:Please, implement a single standard. If it's going to be CAN, do CAN. If it's going to be RS485, make it RS485. If for some strange reason you decide an opensource version of something like DH485 or DH+ is a good idea, go right ahead. But please don't play mix and match with standards like that. I would like to have off the shelf tools to figure out what the heck is going on in a system, and putting RS485 over CAN seems like a very cromulent approach to the problem.


It's just about what chips we can use to do this, and what options are both inexpensive and functional enough. On the software side it's just dumb serial coms. We are not creating a new standard, just using a subset of an existing one.

Xenocrates wrote:It may not happen at maxiumum speed, but it will almost always happen at some level of speed. I can see a lot of potential issues if the drivers belatedly find out they were supposed to be going in the other direction, if you've got a largish jerk value and a very high step rate (Which I thought was part of the point of over-specing the processing and step generation so far.


That has been taken into account yes, we are planning for all that. We are pretty familiar with step generation and what can/will happen :)

Xenocrates wrote:I can think of more than a few things, for example, the Mill/turn center Generic Default is building, or if you want to have your main drivers off board from the Smoothie, such as if you were using the large Gecko drivers for high torque Nema 23's or other large/high amperage/high voltage steppers.


Right now, we don't plan for this to support controlling main drivers. Maybe it'll work well enough that this is something we can play with ( in theory it should be possible ), but it's not a planned or announced feature. Right now this is limited to extruders, and maybe later on controlling things like valves, relays, spindles, etc.

User avatar
626Pilot
ULTIMATE 3D JEDDI
Posts: 1684
Joined: Tue May 14, 2013 12:52 pm

Re: Smoothieboard 2 Progress

Postby 626Pilot » Mon Jan 09, 2017 10:07 pm

Is there a way you guys could use opto-isolators, or some other trick, to make it so that we can hot-swap a hot end? If I do that now, I run the risk of burning out the thermistor port. Would be nice if we could do this for manual work (swap hot end with probe, swap hot end with other hot end), as well as doing tool-changers in the future!

arthurwolf
Prints-a-lot
Posts: 21
Joined: Sat May 24, 2014 3:36 pm

Re: Smoothieboard 2 Progress

Postby arthurwolf » Tue Jan 10, 2017 3:37 am

626Pilot wrote:Is there a way you guys could use opto-isolators, or some other trick, to make it so that we can hot-swap a hot end? If I do that now, I run the risk of burning out the thermistor port. Would be nice if we could do this for manual work (swap hot end with probe, swap hot end with other hot end), as well as doing tool-changers in the future!


We are definitely not adding that to any of the boards themselves.
But we have a planned series of extension boards : https://docs.google.com/document/d/144EbmhN6z-J2V_Zw7GfJpZrfD-B0dC3cuea9oWPgxNM/edit# and what you want to do could be implemented as an extension board.

User avatar
626Pilot
ULTIMATE 3D JEDDI
Posts: 1684
Joined: Tue May 14, 2013 12:52 pm

Re: Smoothieboard 2 Progress

Postby 626Pilot » Tue Jan 10, 2017 7:30 pm

Slightly offtopic, but do you know if anyone is working on an arm solution for "desk lamp" type articulated robots, like this one?

RobotArm.jpg

arthurwolf
Prints-a-lot
Posts: 21
Joined: Sat May 24, 2014 3:36 pm

Re: Smoothieboard 2 Progress

Postby arthurwolf » Wed Jan 11, 2017 10:58 am

626Pilot wrote:Slightly offtopic, but do you know if anyone is working on an arm solution for "desk lamp" type articulated robots, like this one?

RobotArm.jpg


I've talked to at least 4 different persons working on adding that to the Smoothie code, but I don't believe any of them have any public code yet.
It's one of those things that will happen at some point, but hasn't yet.


Return to “Smoothieboard and variants”

Who is online

Users browsing this forum: No registered users and 1 guest