[__Britt]

Where did we land on using the SAMD21 at the primary controller (vs the sub axis controllers)?

The official version of Grbl on ARM is not out yet. You'd have to use something like this; which is a 3rd party effort: https://github.com/terjeio/grblHAL

I have not tried to use it yet; so I don't know where it's limitations, pitfalls, or bugs, if any, would be.

ceramic magnet at the end of the shaft

Being power steering motors; it would have to have sensors; for two reasons: 1) safety, so it's probably (hopefully!) got a redundant set of them; and 2) it needs to work smoothly at zero to very low RPM, which a sensor-less driver can't do (you don't get any back-emf if it's not moving, so sensor-less drivers start up blindly, and expect the motor to fall into sync as the output frequency increases - works well for RC propellers and rotors on drones; doesn't work well at all for servos, which is what that power steering motor essentially is). However, if the motor was positively geared to the steering box, I suppose the commutation angle could have been deduced from the steering angle sensors.

honestly I am not sure I totally understand what bootloaders do

It's more like the first stage of the BIOS on a PC than the operating system - it runs, well, at boot time; and allows you to load the main program onto the flash using something other than the chip's native programming protocol. It's not technically needed if you are using the manufacturer's programmer (or an equivalent) but if you want to have your board be updatable by people (customers or field technicians) using just a standard PC (or smartphone, etc) then you need one. Arduinos, being designed for beginners, were intended to be used with standard PCs - and thus the standard method of sending your main program to the Arduino's processor is over the serial port (or in the case of later Arduinos, the processor chip's built-in USB port); and that's where the bootloader comes in: it runs at startup, checks for specific conditions required to trigger the upload routines, and if those conditions are found, starts to communicate with the upload program running on the PC (the Arduino IDE uses several different command-line programs, depending on which kind of Arduino it's talking to; but for Unos, it's AVRDude - you will have seen that in the build process logs part of the window when sending a sketch to an Arduino). Then, the bootloader copies the man program code that's incoming from the serial or USB port onto the flash, verifies it, and then reset's the Arduino.

If the requisite conditions for upload are not found at boot time; the bootloader just jumps right into your program's main() function (er, close - it executes the C++ automatic startup routines first, so that your global variable's constructors get called before main()).

re: crystal - a bit confused here, I understand the relevance of 32.768 khz, but I thought the oscillator was responsible for timing cpu cycles....but how does a 32.768 kh produce a 48 mhz cpu cycle?

The SAMD21 (and most of the other ARM processors I've encountered recently) use a PLL (Phase Locked Loop) to generate the main system clock. That PLL in turn uses the 32.768 crystal (well, actually it's an oscillator being driven by the crystal, but I digress) to adjust the actual output frequency of the 48Mhz oscillator to keep it right at 48Mhz regardless of supply voltage or temperature fluctuation. Setting this up on the SAMD21 is one of the first things that the bootloader does; and it expects to find that crystal connected (if you wrote your own bootloader - or didn't have one at all; and just did the setup yourself - you could, in principle, omit the crystal and just run the 48Mhz oscillator "open-loop" - and your clock speed would vary, but be somewhat close to 48Mhz, and for some applications that's good enough). I've read comments on forums (I didn't verify this myself by reading the bootloader source code, though) that the Arduino SAMD21 bootloader goes thru a configuration briefly at boot where the 32.768Khz crystal is the only clock running, and is the CPU's clock - so if that crystal is missing or defective the Arduino bootloader will hang there (no clock).

I figured that soldering down a crystal and two capacitors was easier than re-writing the bootloader and sorting out any communication issues that may spring from not having a dead-on 48Mhz clock rate.

re: precision voltage reference: is a zener diode sufficient for this, or is that not considered to be a precision reference?

It isn't, per se - but precision is relative. In this case it will be good enough. Or, there are a bunch of voltage reference ICs available, or for this application, a voltage regulator feeding into a 10-turn trimmer pot would probably be OK.

encoder: these are hedl 5540 encoders

Well, they worked OK back when it was doing teeth, so.... sure, I guess? Assuming you are reading the encoders at the full edge count you get four times the optical lines of resolution, so then there's 2000 states per revolution. Multiply that by whatever the ballscrew drive factor is (turns of the motor per inch or MM of travel); and you get the actual resolution of the system (steps per inch or MM, depending on which unit system you are using). Multiply that figure by the desired travel rate (inches or mm per second) and you get the rate in Hz that your quadrature decoder ISR needs to run at.

Assuming a 1:1 belt ratio, and 5mm per turn ballscrews, that 500 optical lines would give you (500 x 4) x 1 x (1/5) = 400 steps per MM.
Assuming that you want a 100mm/sec travel rate for rapids, then (100 x 400) = 40000.

So, for the above example, your quadrature decoder ISR would need to be capable of handling a 40Khz trigger rate.

It seems like developing these boards is gonna take a bit, I was thinking about ordering a SAMD21 dev board to start familiarizing myself with it, thoughts?

I would. Any of the SAMD21-based Arduino's will do (or a clone).

the lead screws have no rear support bearings on any of the axis!

Wat. Let me repeat myself: Wat.

Unbelievable. Even cheap chinese ballscrew kits for DIY wood routers include support bearings on both ends.

[mtraven]

thanks for the clarification on bootloaders. As a novice, I will probably load a standard bootloader, whereas is sounds like you do some custom stuff there, right?

so I will stick to a mega as the main control board, that will be easy enough to upgrade in the future when ARM compatible grbl is more developed.

Seems like oscillators are kind of like a "reference frequency", but actually generating the cpu clock(s). I don't want any problems there, so not a problem to include the oscillator, just need to decide on which one, some are adjustable...dont think I need that, but there are 2500+ oscillator crystals in the 32.768 frequency on digikey and its like reading a foreign langue to me. SMD chips are strictly re flow right? SOJ seem like ones I can solder by hand? The there are 2, 3 & 4 lead packages. uggg makes my brain hurt.

on the encoders-- so to get the 4x resolution, you are registering both the rise & fall on two encoders. got it. I am going to pull the stages off tonight and come up with some of those measurements and I will update the math. The datasheet said 100khz max frequency, is that comparable to the 40khz trigger rate you refereed to?

ball screws --im glad you are as outraged as me. After I calmed down, I thought /looked at it some more...it seems they didn't use rear bearings in order to "cheat" on the travel. They get an extra couple inches where the bearing block would be. Not defending them, I still find it unacceptable, but at least I can see what they were thinking.

However, if the motor was positively geared to the steering box, I suppose the commutation angle could have been deduced from the steering angle sensors.

It was pretty close to a 1:1 belt drive to a lead screw replacing the steering rack. I had similar thoughts about the speed this motor would have been designed to do....slow, slight back and forth motion most of the time. but then when you turn, I'll bet that motor has got to drive it pretty fast. I am really interested to see what I can get out of them, speed, duty cycle, torque, ect. Also like to see if I can run them higher than the 12v they were designed for. The motors where $10 /ea, so I am good with taking some potentially destructive risks.

[mtraven]

encoders & ballscrews: encoders 500 lines x 2 encoders = 2000 events per motor shaft rotation
belt drives 3:1 = 6000 events per ball screw rotation (which is 0.100" in linear travel)
ballscrews: 10 tpi (0.100" / rotation) *interestingly my dial face is 0.100" / rotation...this creates a kind of spooky 1:1 link between the sprocket & dial that will ONLY occurs with a 10tpi screw and 100k dial. Also I was amazed at the steadiness of the dial as I advanced the ball screw, I am very used to acme threads and it makes a world of difference.
total: ( 6000 events / ballscrewRotaion) x (10 ballscrewRotations/ 1 inch) = 60,000 events /inch or each event(step) being 1/60,000 [23,622 events / mm]
i doubt this "fine" system is going to move at 100mm/s, but if it did, that would be 2,362,200 events/second (2.3 mHz)

at this point, I feel like my math is off, but i have been over it several times and im burnt out, im sure I'll see my error tomorrow.

I head your point about grbl not "stepping" faster than 30k...but there is no reason the sub axis boards can't be reading encoders & adjusting the +-10v signal as fast as they can right? I feel like that's the whole reason to use the samd21.

So when you say

your quadrature decoder ISR would need to be capable of handling a 40Khz trigger rate

this is the interrupt pin on the samd21 (through a 5-3.3v converter), correct? But thats actually 2 inputs, right? and wouldn't that mean a trigger rate of half the events? still have to process all of them, but it is two different pins being triggered half the time....unless there are shared resources between pins. I cannot find anything like max ISR handling frequency in the samd21 datasheet. But does the actually triggering take more than a clock cycle at 32bits? beyond that, there the time to execute the ISR handler...but if we just talk about the triggering, shouldn't it be able to do this at the better part of its speed (48mhz)?

I gotta say - would an extra inch of machine size to put in a bearing have killed them?

-so in the X axis, they needed the travel to move from the mill to the laser. Keeping that travel would add the thickness of the bearing block + 3/4 length of the carriage (~3in). So probably 4" total. See they stuck the nut all the way to the near side of the carriage and they run all the way to the end. I know this because of where the endstops are placed. The thing is, they had the space to do this.
-then there is the y axis, which is unusabley long with all sorts of space for a bearing block, still nothing
-the z axis, i admit is a little trickier, but not too bad.
-kind of seems like poor planning, but maybe they just didn't care.

Probably quite a bit. Do you know what they were out of?

either a land rover or a tesla...been used in both, but I think its discontinued now

Just like a stepper motor, they are going to be current driven devices; so the maximum voltage going into the controller will be determined by the chips (MOSFETs or IGBTs, mostly) that you use. More available voltage will translate to higher peak RPM and torque at speed.

they really are low resolution steppers aren't they? i figured about the circuitry, my concern was more about hitting the actually coils with higher voltage...though they are some heavy windings, at least 12, maybe 10 gauge enamel wire.

[mtraven]

Your outline of your chip selection process was very helpful..I mean I am still terrible at it, but at least that process minimizes my frustration. I have started building the circuit, got most of the basics done (pwr connections, oscillator, ect)

I was just starting to work out the 5->3.3 voltage dividers when I remembered the encoder signal goes straight into the driver. So i popped open the data sheet, confirming those signals do go into the driver. Now there are internal connections between the original computer & the driver rack, so maybe its just a passthrough.... Then looking at the block diagram (see page 14), there are several indications of +-12v. And on page 16(pinout), there are two pins labeled +-12v OUT. (Other where refereed to as AUX voltage). Thought these might be the Monitors (I & N), but those are separate outputs on the pin out. I am have a bit of trouble understanding the flow and what is happening, but I think there is at least a chance that driver itself was handling the PID. From the block diagram, we see the encoders go into Frequency -> voltage converter (not familiar with those) and then become -Tacho input. All I can work out for sure is that the driver itself was doing SOMETHING with the encoder signals....Can you shed some light as to what is happening there?

the encoders have A, B and I outputs (as well as there inverted compliments). The "I" channel is just 1 div / rotation. The driver does not seem to use this (or even bring it in as an input), but in theory, this sounds like a useful feature to ensure there were no missed divisions on the encoder. But theory doesn't always match up to practical applications, and I have no experience with that. So I turn to you for advice.


re: programming header - how does this connect to the computer? Its been a long time since I have tried anything with that, but I recall making a header -> serial cable. So do I need to buy / make a cable for this? And then what software to flash the chip (i think atmel studio? ) Then once the bootloader is flashed, I can upload sketches through usb like a normal arduino? Also curious what you write code in? The arduino IDE is cute, simple & great for beginners...but kind of useless for building sizeable projects. I had switched to Sloeber, which is built inside eclipse. I went with it because I knew the interface a little bit from some JAVA programing I did. So what do you recommend?

[mtraven]

hey sorry for the delay, winter hit fast and hard here this weekend, and I was not ready. Also I bit into that soldering iron station project and ended up on some tangents, useful, but tangential nonetheless.

Um... which SAMD21 dev board did you get?

this one didn't put much though into it, just wanted something to try.

Um... typo?

yup


great info on the opto / grounding stuff. a while back I was running stepper signals through opto's and came into some bizarre behavior, mostly when stepping fast (<500uS between steps). I began to suspect the optos were slow as they were part of my "old electronics inventory". I had 4 different kinds, most of which did not have a modern standardized format (i am sure you've seen old datasheets)....not really knowing what I was doing, and lacking a scope, it was days of reading sheets and trying to work out the math, I did eventually settle on some 4n24's i had around, I knew they were the fastest I had, but never truly knew they were fast enough. So that backstory leads me to my soldering station project. So as I was building a couple of simple power supplies and a pwm mosfet circuit, I spent some time re-familiarizing myself with using a scope (its been at least 10 years since I used one). OMG what a useful diagnostic tool! The way you felt about the microscope is how I feel about the oscilliscope. I had spent years trying to troubleshoot signals with just a multimeter and now I am staring at a WHOLE new world. And more importantly, I can SEE the results of different components. For example, I sat there and played with all sorts of combinations of resistors & caps on my voltage regulators and got to see the subtle differences they made. I learn quite well from that sort of direct feedback. They when I got to the opto that drives the mosfet, I swapped some of those other chips in & out and got to see exactly how signals were getting cut off....really cool. Tonight I would like to compare the analog out of an arduino nano (328) and the samd21. You had mentioned the method of generating analog signals is much better on the samd21, so I would like to see that.

I am still working on this damn soldering station...only part I didn't breadboard was the thermistor circuit, as I have wire many of those....but it is an PTC(although I am starting to think its actually an RTD) and I am used to NTC. thought that would only matter in software, I can measure the resistance as I heat it and it climbs, but then I stick in a voltage divider and end up with the full voltage. I think its got to do with the size of the divider resistor, but I haven't quite zeroed in on it.


When that is finally done, I do plan to start building a proto type axis control circuit. More generally, my 1st goal is to get 1 axis moving around with an arduino.

[mtraven]

....not have enough current going thru it to drive the chip's input;

thats good to know, and I getting into that ballpark at 10k : 20K or is that more when you get up into mega ohms?

Basically, yes. There are a wide variety of opamps that would work; however that one is reasonably cheap, has the specs needed, and is more-or-less ubiquitous. As opamp applications go, this isn't a terribly demanding one.

my question was a bit unclear, I was asking if its ok to take the 3 op amps from the schematic you drew and run then into a single quad op amp chip. Like could that create interference issues or something. I think the answer is its fine, but I just want to confirm.

it's got it's own internal PID loop

is this whats picture in the block diagram for the driver? I thought it looked like a PID loop...thats why I was hoping it handled generating the analog input signal. I know thats not what it is doing, but it is a similar looking circuit, no?

I can see the pins on the samd21, so that makes it a QFN. I am not saying I cant do it and I will at certainly at least try, its just intimidating. That might change when I get my soldering iron station going. My old one is on its last leg and causing me a lot of soldering frustration.

(not surprising really, though - this is a CNC machining forum,

yah I really came here looking for more general advice on what to make of the machine...then decided thats not really the firs step, its swapping out the brain. Thanks for the forum recommendations, I will check them out.

That's part of the C standard, and the Arduino build system includes it automatically for .ino files... #include <stdint.h>

has it always been? When I learned C back in high school (2002 ish), it was all int, doubles, words, ect. My understanding is that the size of those was not fixed across different architectures. Then when I got into arduino, they were using the same vars. Then last year when I really started studying some of the libraries I used, I can across the _t nomenclature and have used it ever since. Only complaint I have is that int8_t i doesn't roll of the key board as smoothly as int i. From your explained naming system, I think we would be able to read each others code fairly easily. I use camel case as well...its also how I do nearly all file names and I have been doing that pretty much since I started coding. The crazy thing is, before you called it camel case, I have NEVER heard that term before, didn't even cross my mind that there was a term for it!

re: common grounding --I have some experience with this, both good and bad. I understand the need to have a common reference(ground) voltage, where I have been troubled in the past is when I bring opto isolators into the picture. My question is if you take the ground from the power supply that is supplying power to the output of the opto and connect it to the common system ground, does that not break the optical isolation?

I get the feeling that most people here have only gone as far as assembling pre-packaged module

the "why make it when you can just by it type"......I fall more into the "why buy it when you can make it" mindset. More so with mechanical things, but slowly getting there with electronics too.