Yes. Surface mount can be ridiculously cheap. Also choose parts starting with “MF” in the part number, as labor is free. (Unless a specific manufacturer is key to the design.) Once you have a design put together you will also see a nice price graph at all volumes for both the prototype and production level services.
Paul Stoffregen is a solid contributor to the Arduino community and an excellent engineer. His products are elegant and unsurpassed power for your $, yea it’s diffrent but he supports what he makes and with pretty easy to install and use utilities.
If you can’t connect to a teensy your going to have a hard time with the Mega or CNC in my opinion.
Thank you
@bee posted a link to smd headers… the datasheet says the following:
The product will withstand exposure to 260°C peak temperature for 10 seconds in a wave solder application with a PCB
Is that component compatible with whatever macrofab uses for surface mount boards? I’ve personally have melted headers before with my heat gun as I tried to melt nearby solder for a SMD component and had to switch to a soldering iron to get the job done (which I failed at miserably).
[quote=“madgrizzle, post:115, topic:10453”]
Would it be safe to say that if you want assembled boards you should strive for surface mount?
[/quote] I have been told that. Seed and elecrow run specials for assembled boards from time to time on their websites. If you ever order the boards in bulk assembled the cost for hand soldering does not seem to be that high After all the maslow motor shields that are currently being made all require through hole soldering for header pins and dc power jack, etc.
Seems true. But as it is, I can’t afford a prototype board that’s fully assembled and looking to get the cost reasonable. I don’t have a problem getting the board unpopulated and doing the soldering myself… just exploring options to see if I can get the cost down using SMD.
When you consider my answers, please keep in mind that I am not a EE! Or even a design or production engineer.
As for your header, it should be fine. The choice of solder paste and the reflow oven take this into account. We run thousands of headers like this with no issue. If you want to be absolute certain, send the specifics to support@macrofab.com and they can check for you.
As to SMT vs PTH, the only common use for PTH today seems to be in very high durability environments where the board gets coated or potted, and even then, SMT is making inroads. Once you have designed for SMT, the benefits just keep on coming. SMT is also where the manufacturer innovation is focused.
Thanks… I’ll see what I can come up with and what the ultimate cost will be for the prototype.
Excited to hear about your project. I’ve been using Teensy since the original version and really like the library support, form factor, and speed.
Does it make sense to add motor current monitoring? I suppose we could already use a lack of encoder feedback to deduce a stall. I apologize if that is already being done.
I don’t know how useful it would really be. besides the trick of monitoring the
encoder, we already can say that there’s a problem if we need to apply full
power for ‘too long’ (based on the PID loop ramping up power from it not keeping
up), right now that’s not very useful because we don’t do acceleration planning,
but once that’s added it should be very useful.
David Lang
1 Like
Just saw this and thought it was relevant https://www.youtube.com/watch?v=Nlx9YWLgklM
1 Like
I absolutely want to add current monitoring. That is actually a big reason that I chose the driver chip that I did. I think having current monitoring would let us do a lot of interesting things like better pull tight measurements, more advanced self diagnostics, protection against the machine tearing itself apart at the edges, and possibly even adaptive cutting based on how much force the router bit is experiencing.
3 Likes
An SPI encoder just moves the equivalent of microcontroller logic into the encoder, and now you need unchangeable logic in each encoder instead of updateable logic in just one place. Something deterministic needs to count the pulses, you cannot escape that. R pi cannot poll a dumb incremental encoder reliably.
WebControl sounds like a great idea, but it introduces real timing problems. IEEE1588 can be used to solve them but that requires compatible peripherals and added complexity. There should always be an option to build and test a minimum viable Maslow without networking to test the basic system and rule out problems with connectivity. Network stacks are optional can of worms added on top. Every few months there is a new hot IoT networking service that will be abandoned and unsupported in a few more months. If UART is the base implementation, anyone is free to add the flavor of the month Tembo or whatever on top. If the base implementation is a network stack, it must be extricated from the code before a new flavor can be added.
ESP32 tends to brown out when accessing the network. The small regulators don’t have enough input capacitance. Program resets don’t always happen cleanly. Heat can cause instability.
If a machine with keyboard and mouse is necessary for CAD/CAM and accessing WebControl then why require a R pi at all?
And what exactly do you plan to have run grbl? It is the sub movements that I was talking about quing up, not G code. I was not suggesting
I was suggesting an E stop button, some limit switches, jog buttons(or joystick), DRO(Digital Read Out), and over current warnings. But because of the geometry, DRO requires simulation. Sounds fancy, but its just a coordinate transform back to (x, y).
I know, I was a control systems advisor supporting these at competitions. No one uses the SPI because it is so unreliable past a few inches of cable. CAN is much better.
The spreadsheet is never required. It is just a simple way to generate commands which tell the machine move here, then here, then here without ever having to use a CAD package, or G code interpreter. Good for troubleshooting, calibration scripts, and simple cuts. Jog controls could serve much the same purpose. but it is a feature I would want in some form.
These are just my opinions, as the thread title indicates. I don’t fully understand what your plan is, but I don’t need to. I’m sure whatever you come up with will advance the state of Maslow.
1 Like
Currently, WebControl doesn’t talk to the encoders/motors at all. It’s just a replacement from GroundControl and its the arduino controller that does all the talking to the encoders/motors. Webcontrol = web-based version of ground control. There has been discussions of moving the arduino’s functionality to WebControl but I too am concerned about how well that can be accomplished… It might work though… I just think the juice isn’t worth the squeeze and suggested maintaining at least some type of arduino (or whatever microcontroller) to handle encoders/motors maybe at a more basic level than the arduino does today. Today, the arduino receives GCode from webcontrol/ground control, parses the gcode and creates the individual steps. My idea is to let the RPi do the parsing/step creation and just pass the step commands to the arduino. The arduino would just then interface with the motors/encoders, manage the PID loops and report errors.
2 Likes
An SPI encoder just moves the equivalent of microcontroller logic into the
encoder, and now you need unchangeable logic in each encoder instead of
updateable logic in just one place. Something deterministic needs to count
the pulses, you cannot escape that. R pi cannot poll a dumb incremental
encoder reliably.
moving the logic to the encoder greatly reduces the chances of electical noise
causing problems
WebControl sounds like a great idea, but it introduces real timing problems.
no it doesn’t, WebControl doesn’t do anything that’s timing critical, it still
uses the arduino for all the deterministic stuff. It just replaces GroundControl
and talk over the serial/USB port to the arduino.
what we are discussing here is the potential to combine functionality
IEEE1588 can be used to solve them but that requires compatible peripherals
and added complexity. There should always be an option to build and test a
minimum viable Maslow without networking to test the basic system and rule out
problems with connectivity. Network stacks are optional can of worms added on
top. Every few months there is a new hot IoT networking service that will be
abandoned and unsupported in a few more months. If UART is the base
implementation, anyone is free to add the flavor of the month Tembo or
whatever on top. If the base implementation is a network stack, it must be
extricated from the code before a new flavor can be added.
wifi, ethernet, and http are not ‘hot new technologies that will be abandoned in
a few more months’
Yes, the network stack adds complexity, but it eliminates the complexity of kivy
and cross platform GUI development. It also means that you can have two displays
hooked up to the machine at one time (desktop and phone for example) which makes
things like tweaking sprocket positions MUCH easier)
wifi and ethernet are more immune to electrical noise from the router than
serial and USB are
ESP32 tends to brown out when accessing the network. The small regulators
don’t have enough input capacitance. Program resets don’t always happen
cleanly. Heat can cause instability.
I haven’t heard this part before, details please? how much heat is needed to
cause problems? can additional input capacitance be added to the board it’s
mounted on? how much would be needed?
If a machine with keyboard and mouse is necessary for CAD/CAM and accessing
WebControl then why require a R pi at all?
-
people frequently don’t like to put their ‘good machine’ and high end
monitor in their hot, dirty workshop. -
workshops are typically not ideal places to do CAD/CAM work (their
layouts are designed for shop work, not computer work) -
it’s really useful to have something that you can reach at the same
time you can reach/see the sprockets close up -
the delays in serial processing and getting the next g-code command can be
significant when there are lots of tiny moves (the same reson that 3d printing
commonly uploads to an SD card and then prints from there rather than printing
through serial)
And what exactly do you plan to have run grbl? It is the sub movements that I was talking about quing up, not G code. I was not suggesting
two possible options that we’re talking about here (besides the possible answer
of keeping two processors)
-
run a fork of grbl on one core of the ESP32 (while using the other core for
the network and webcontrol) -
run a fork of grbl on the Pi (probably dedicating one core to it), IF and
ONLY IF we find that the timing requirements can be relaxed due to not having to
count pulses.I’m not especially worried about keeping super precise timing on
the Z axis, the machine is slow enough that being a little off on stepper pulses
for the Z isn’t going to hurt much, even when doing carving type cuts, and the Z
axis doesn’t have a huge amount of momentum that will cause problems if the
stepper isn’t turning extremly smoothly like the main axis of a CNC that grbl
was written to handle.
I was suggesting an E stop button, some limit switches, jog buttons(or
joystick), DRO(Digital Read Out), and over current warnings. But because of
the geometry, DRO requires simulation. Sounds fancy, but its just a
coordinate transform back to (x, y).
e-stop is a good idea
over current warnings and voltage sag warnings would be good, but that’s going
to depend on the motor controller used
WebControl almost does away with the need for jog buttons (due to the ability to
use a smartphone/tablet as your jog controls)
DRO is trivial with something like webcontrol and/or a Pi being involved
limit switches are MUCH harder than you would initially think. This is an issue
we’ve gone over multiple times, but the root problems that we have not been able
to solve yet are:
-
you have to know how long chain 1 is to know how far you can extend or
retract chain 2 without either falling off the workpiece or trying to pull the
sled apart. -
since the chains leave the sprockets (and the sled) over a 70 degree angle
depending on where you are on the workpiece (10 degrees to 80 degrees), we have
not figured out a good way to mount limit switches.
I know, I was a control systems advisor supporting these at competitions.
No one uses the SPI because it is so unreliable past a few inches of cable.
CAN is much better.
I think there is spi the electrical interface, and spi the data standard, it
looks as if you can also use the spi data standard with the rs422/rs485
electrical interface to get the noise immunity and longer distances needed.
I’m ok with a CAN bus as well, the key idea is to keep the pulse counting on
deterministic hardware close to the encoders while allowing for querying of the
location from a less deterministing processor.
The spreadsheet is never required. It is just a simple way to generate
commands which tell the machine move here, then here, then here without ever
having to use a CAD package, or G code interpreter. Good for troubleshooting,
calibration scripts, and simple cuts. Jog controls could serve much the same
purpose. but it is a feature I would want in some form.
I’m lost a bit, what is the feature that you want? you worded the earlier post
as compatability with this spreadsheet.
grbl has acceleration settings for each axis (which really should end up being
translated for each motor, but that is far more complex, so we’re hoping to be
able to get away with faking it with x/y acceleration limits, possibly zone
adjusted for different areas of the workpiece)
These are just my opinions, as the thread title indicates. I don’t fully
understand what your plan is, but I don’t need to. I’m sure whatever you come
up with will advance the state of Maslow.
in spite of what it may sound like, we do want your input as well, it’s the
community input on designs that has made the maslow what it is today (just
remember, working hardware kits that ship trump theory, however much experience
there is behind it. I’ve suggested a lot of things, not all of them have been
accepted, and not all of what has been accepted has turned out to be right after
further experience)
right now, we don’t have a solid plan for the next gen of controllers, we are
exploring options.
It does seem like the future is likely to be WebControl instead of
GroundControl, simply to be able to offload the “cross-platform GUI problem” to
browser developers and allow multiple connectivity. Even on a single PC
connected directly to the maslow, the ability to run a python program to talk to
the arduino and use a browser pointed to the local webserver avoids a lot of
headaches
One problem we have is that the calibration is split between the two processors,
Ground/Web control issues commands, takes measurement input, and calculates
parameters, which then get loaded into the fimware eeprom. If anything changes
about the calibration routine, both pieces of software need to be upgraded in
sync.
This also means that we can’t use other software to control the maslow via
serial, at least not until after the calibration is completed, and the other
software isn’t going to understand the motor position tweaking that ends up
being needed far too frequently.
I would love to have us run something that looked to the outside world like
grbl and have the option to drop Ground Control/ Web Control and instead use one
of the many existing options out there instead (eliminating a significant amount
of software development/maintinance) but the issue of doing the calibration and
doing the sprocket alignment are slowly convincing me that we are unlikely to
ever be able to do so 100%
it would be possible to make the WebControl also expose a grbl-like serial port,
passing the g-code through, but I don’t know how much it would end up being
used.
David Lang
1 Like
I would argue against this. I think we should either
- try really hard to run a close fork of grbl on a separate controller (arduino
or other), including trying to get any maslow specific changes in the upstream
repo.
or
- try really hard to run grbl or linux CNC entirely on a Pi
we don’t have nearly enough software developers here. There is a huge amount of
value to being able to leverage the developers of grbl/linuxcnc to
maintain/develop the codebase,
splitting the work that grbl is doing into two pieces running on two processors
seems like a really bad idea. Besides the maintinance issues, grbl keeps the
individual steps in memory and re-writes them as new g-code is processed (as it
learns the next move, it can decide that it no longer needs to come to a
complete halt at the end of the current move, and so re-writes prior steps to
not decelerate to a stop and instead to only slow as much as is needed to be
able to transition to the next move given the acceleration/jerk limits). This is
really hard to do if the two parts are on separate boards.
David Lang
1 Like
That’s sort of what I’m suggesting except isolating the low-level motor control part to an arduino. In essence turn the arduino into an intelligent motor controller where you only send it pid set points that the grbl routines generate and just have the controller responds with error values. Might have to incorporate some kind of settings to adjust pid values, but that’s really it (I think).
1 Like
This. Stand on the shoulders of giants and contribute upstream for edge cases. We should avoid reinventing wheels with our limited resources.
-Jeff
1 Like
Can you elaborate on your statement? Why? Confirmed in actual use?
-Jeff
This is a tier one requirement IMO. We should not be without it. Safety first.
-Jeff
1 Like