Firmware wishlist

And for sure, if you want to get your work accepted in an open source project, you have to clone. You have to make a series of small changes so that they can be reviewed and tested in isolation, A big cut-n-paste reorganization just is not possible where a more-or-less loosely knit set of people are working on the code.

As far as understanding the code. Start with the ino fiile. When the Mega is powered up, the setup() function is run. After that is over, the loop function is run. It never ends – it just keeps running until the Mega is reset or
powered down. The code is actually commented reasonably well.

3 Likes

With respect, I’ve been trying to read the code but the present arrangement makes that very difficult. The majority of what I’ve suggested are improvements to readability, not performance. Of course performance is more important, but if I cannot follow the code, I cannot help.

Tasks, are separated into functions, technically true in that what you have is a computer program. But everything seems to be the names of things, often very generic things, not the action they perform. So the code is not self documenting and it is also poorly commented. There seems to be very little concept of user interface.

Thus my request for a high level overview. I was hoping that would help reduce the need for me to ask 1000 questions. Those that wrote the code understand the flow because it was in their head prior to being written. The rest of us don’t have that advantage.

I’ll give a few examples from cnc_ctrl_v1.ino
Right off the bat, good to see comments, wish they were more useful.
Left and right are not axis. An axis is a fixed reference line, usually orthogonal to other axis. These change length and angle constantly and are right angles to nothing. A ‘position’ on this ‘axis’ does not map to any point on the workpiece, it can change any time a different axis changes(chain wrap). It is not a position, it is a length, mostly represented by an encoder count. Wait, encoders are a different file, or 2. The only pseudo fixed property is the origin. These are vectors… no, because the setup is only about pins, this must be a hardware driver. No, even the definitions for direction are defined elsewhere. System? really? couldn’t get any more generic. Are they motors? No, motors are elsewhere. Motion, no. Kinematics, no. Is it a motorgearboxencoder whatever the heck that is? No. It has PID, values, is it a PID controller? No, that is elsewhere. What the heck is an axis?
So many names for different files describing essentially the same thing, but none of them really capture what is inside. There is no clear distinction between hardware and the theoretical model. This is a big problem because now you cannot change one without breaking the other. Moving on.
Serial.print(F(“PCB v1.”));
Serial.print(getPCBVersion());
Oh, print the version, then get it. Novel approach.
if (TLE5206 == true) { Serial.print(F(" TLE5206 “)); }
Serial.println(F(” Detected"));
What kind of value does TLE5206 represent? What type? Anything nonzero is true. What file do I need to look in to find out? Doesn’t matter, it is always " Detected" true or not.
sys.inchesToMMConversion = 1;
really? That had to be just here? What does it mean? There are 25.4mm per inch, not 1.
// Set initial desired position of the machine to its current position
leftAxis.write(leftAxis.read());
rightAxis.write(rightAxis.read());
zAxis.write(zAxis.read());
The comment shows human knowledge that the desired(commanded) position is not necessarily the position the machine is at. The statements imply that the machine makes no such distinction.
reportStatusMessage(STATUS_OK);
Now thats optimism. Couldn’t possibly be any other way. Could it? Do you think maybe we should check? No, it couldn’t possibly be in setup as the result of a brownout reset or serial monitor opening and all the motors are still screaming away. What is even the point of reporting status if it isn’t checked. By the way, why are status and state not defined together?

I understand that what exists is the result of a messy historical process. The scope of the project grew and artifacts were left behind. That happens when you are really on to something. I am not looking to remove any optimizations, just package them, so we can also provide optimizations for different hardware that the end user may have. I’ll just say it, I am not building a default maslow. I have different ideas, but need the firmware to evolve to accommodate it. I am not good enough to do it myself, so I’m pushing a little.

If I had to start from scratch, the way I described is how I would start. So as I slowly learn what the code is doing, I’ll cut and paste into that framework.

To be fair, I have to admit that after writing this post I discovered a lot more comments than I saw initially. Because I was looking for a high level overview, I was focused mostly on the header files. Looking for an API basically. Turns out most of the comments are in .cpp files which I just skimmed because I wanted to put pieces together, not see how each piece worked. So, if this post sounds sarcastic, sorry. My sarcasm setting sticks sometimes. I am aware that my frustration is mostly of my own manufacture. I should probably just delete, but I spent too much time typing to let it disappear.

Getting one’s arms around a complicated system can certainly be frustrating, and the Arduino IDE doesn’t lend itself to that at all. I find that the PlatformIO IDE or a separate editor that handles complex projects makes it easier to trace things through their paths from serial command to motor movement and back. Doing that, one can see the logic of the design and the way that it will make incorporating other hardware easier. I use the PlatformIo IDE for compiling and uploading as well. It integrates well with Github Desktop.
Without a deep understanding of the present system though, one could not really do a proper job of re-arranging it. Many software projects have foundered on just that thing. Starting from scratch and lifting pieces is a time-honored approach and could work well. Let me know if you need someone to help with testing.

5 Likes

So I was trying to understand the kinematics code today and was hampered by the fact that there were several angles named only with greek letters and I did not have any diagram describing where they are. So I started to think how I would do it and at least 1 part of the job requires nothing more than addition, subtraction. and the pythagorean theorem. Please look at the attached chickenscratch and tell me where I am wrong. It seems like this would be a computationally less expensive method to find desired chain length for a given point.

  1. transform whatever coordinate system you have into cartesian with origin at left motor, only positive values growing down and right, like computer graphics.
  2. split the main triangle (Lmotor, Rmotor, point) into 2 right triangles. All the adjacent legs of both right triangles equal the given coordinates plus a fixed offset.
  3. Each chain length is just the hypotenuse solution to one of the right triangles.

_verifyValidTarget(&xTarget, &yTarget) becomes a simple matter of bounds checking the coordinates, no angles required.
I’m thinking of this with the parallelogram chain in mind, so some small correction factors might be different, but I don’t see why the triangulation math couldn’t be as simple as 2 fixed and 1 variable point.

1 Like

The pythagorean theorem is at the heart of the triangular kinematics, but the motor end of the chain must wrap partly around the sprocket to an amount that varies. Look in the repo for ‘triangular kinematics’ in issues and commits to see discussions of that and some of the other details that take the calculations beyond the simple triangle.

2 Likes

I knew of chain wrap before posting. That was addressed mechanically in parallelogram chain by using fixed sprockets on the sled instead of point mounts so that wind/unwind would cancel eliminating that error. Chain sag is another issue I was already aware of. https://github.com/MaslowCNC/Firmware/pull/369 Variable chain tension requiring varying current for same speed is yet another. Fun with Numbers - Calculating Motor Load Force Also, play in the chain links accumulates for long chains. Are there others?
The thing that all of these sources of error have in common is that

  • They are each in their own right systematic and computationally expensive to model and compensate with an inverse model.
  • Because the magnitude and sign of each error source (along the chain vectors) can ultimately be expressed as a function of position, they can all be combined and eliminated together using a robust (enhanced tbd)calibration routine and a precomputed lookup table(s) of correction values for each position.

There is no need to model each minor systematic effect, just observe the combined effect once, at grid locations, during (enhanced tbd)calibration, then each time a move starts in one of those grid squares, apply the appropriate correction.

leftChainLength   = computeLeftHypotenuse(commandedX, commandedY);
rightChainLength = computeRightHypotenuse(commandedX, commandedY);
leftChainLength   += errorCorrectLeft(commandedX, commandedY);
rightChainLength += errorCorrectRight(commandedX, commandedY);

In order to always be applying the best correction, any moves larger than 1 grid square should be broken into smaller moves. Off the top of my head a grid pitch near 7" sounds about right so that a 6" test square can be cut with only a single correction factor.

Non systematic error sources like linkage slop, loose motor mounts , will not be affected by this approach. The (enhanced tbd)calibration routine could be a IR led, or retroreflector mounted on top of the router over the bit, watched by webcam using machine vision techniques. Or it could use the method I described previously, or they could be combined.

To be clear, these techniques are NOT intended for immediate implementation. This is a pie in the sky wishlist that might go towards creating a requirements specification for a hypothetical future major version.
As such, objections such as “no time”, “too much work”, “that is not how it currently works”, “you aren’t qualified” do not apply.
Objections that Do apply are “We tried X once, but reverted because of Y”, or “We considered X, but chose Y because …”, also “X wont work because of Y.” Preferably Y comes with a link or explanation.

Are there any existing software requirement specification documents? If so, that could serve as the high level overview I have been after.

1 Like

@slomobile nothing personal, but your ‘forum fu’ could use some polish.

This is a pie in the sky wishlist, but speaking with conditional absolutes doesn’t read well. Most of the ppl here are not interested in working on a hypothetical future major version.

We ARE interested in discussing refining, via experimentation and incremental development, knowledge and experience sharing the machine we have, not the one we want.

Hypothetical major future versions already exist, they’re 3 axis traditional 4x8 CNC mills and they start at $4k or so, check em out!

I’m sure everyone here is happy to continue discussing issues that can be improved, refined, streamlined, etc, there are plenty of places to improve, but jumping in, midstream, in the manner that you’ve been in this thread isn’t the best way to go about it, in my opinion.

My best advice for your participation would be to focus on a few small features, or refinements or code contributions that will (rapidly) increase your ‘cache of usefullness’ (my term) to the rest of the people working on the project in various capacities. you’ll immediately find that your (politely worded) suggestions or musings will be taken more seriously and receive more constructive replies in general.

At least this has been my experience.

cheers,

5 Likes

Another feature to add to the wishlist. If we get a camera looking at Maslow for calibration, we can use it for other purposes such as irregular workpiece edge detection and gcode validation. It could also be used in toolpath generation under some circumstances.
Example 1, draw the cut centerlines with a sharpie, camera reads the lines and translates it to a toolpath.
Example 2, shadow profile cutout. I remember in elementary school we created ‘art’ by sitting someone in front of a bright light and tracing their shadow on construction paper. Then cutout the profile with scissors. Maslow could automate that process.

The bulk of this workload would be in software, but mode selection and start buttons are still in the realm of firmware.

I’d suggest extracting the kinematics code you’re interested in and inserting it into a simulator in a more friendly enviornment (Mac&Cheese, WinHose, OS/3, or the answer to everything (Linux, of course)).

Did a whole lot of that shortly after vacuum tubes were the hot thing, found it worked very well.

So what do you have against us Plan 9 afficionados?

1 Like

Plan 8 3/4, BuzzOS, OS/359, Exec 7.9, and your choice from the linked list. Please note that your hardware may not support some of these, they may lack the requisite development enviornment, and the graphics capability may not be adequate

1 Like

You’ll get no argument from me on that point. Tonedeaf is another criticism I’ve heard.
“hypothetical future major version” was my hamfisted attempt to avoid offending those that have already worked so hard getting the project to the working state that it is in, while I suggest alternatives.

For me, these posts are not hypothetical. They are stream of consciousness musings, but they go toward my personal Maslow build in progress. I am sharing them to develop and solidify my own plan and in hopes that someone will be able to use something from them, sometime. If the community wants me to stop, I will, your loss. Again, tonedeaf, you need to be blunt with me or I don’t get it.

If it helps you understand my motivation, I have no desire or intent to focus on a few small features, or refinements. I really don’t care if anyone finds me useful. I am not a tool or an employee. I resent even the implication that such limits are inherent in open source. It is bad for innovation in general to limit oneself to that which is easily accepted. Sometimes you gotta break some eggs.

My maslow needs to pack up small and move to a remote build site without AC power. A CNC mill might do that, but the rails or ball screws could easily be bent in transit. Chain doesn’t care about potholes, waves, or rented help. Everything including spindle runs off a battery and ATV charging system or PV panel. Packing full sheets through the woods is tough so quarter sheets will mostly be used. I cannot burn up full sheets trying to calibrate. I am using the maslow build to increase familiarity with hardware I already own and use in other robot builds, and which I have a use for on site after maslow has served its purpose. 300w motors, 64:1 planetary gearboxes, analog encoders, very nice CAN motor controllers with integrated encoder readers, limit switch inputs, and profile follower mode. I do not have a mega, and prefer not to learn yet another micro. I do have several Teensy and prior to maslow was toying with the idea of implementing CANbus on them. This project provided a plausible reason to tackle that. The increased speed and features of teensy, the bigger motors, and the parallelogram chain theory make this a platform that could test the limits of Maslow. Other things I’ve described are ways I would personally like to use maslow. All that combined equals the need for custom firmware. If going custom anyway, it makes sense to modularize. I wasn’t going to expect the community to contribute all that, I would have to do it myself. That means learning how the existing code works. So, I’m doing that and contributing back what I learn in the process. I have received a mix of very kind help, encouragement and … something else which I don’t really understand.

That sounds like a good idea. Did you have a simulator in mind?
I don’t do Python. I use Ubuntu MATE 16.04 but am not expert having jumped ship from MS after win8.0.

Re: OSs I was an early adopter of BeOS, and just this morning had good reason to recommend reactOS to a grandma still running winXP. Dell Latitude from 1984 with 32mb of ram and 768mb hard drive still runs 24/7 with puppy linux.

I believe there’s some existing simulator code already, but basically you plot the current bit position with whatever graphics your OS provides. Of course it’s somewhat more involved to strip down the code, simulate the motor/sled motion, and feed in the appropriate moves

There is a simulator in the ground control code, but it doesn’t take into account chain sag or tolerance

There are a couple big problems with trying to have a massive lookup table to pre-compute all the errors.

  1. how do you measure where the bit actually is at any point to determine that it’s not where it should be (what do you reference against, how accurate are your measurements)

  2. where do you hold this massive lookup table, the arduino has a very small amount of storage available.

I really so like to have people dig into the code and if you can submit documentation patches as you figure things out (or think you have and want confirmation), it will help more people down the line.

remember that the quadralateral math was there first, and it’s a lot uglier than the triangulation math, but a lot of the variable names were just re-used. Also, whoever named them had a diagram they were matching, unfortunately time, and the change in forum software has caused us to loose track of that diagram

nope, the code is the specification.

There has never been a complete model posted, there were early models posted,
but then new corrections have been added and the threads on them (and any
pictures there) focused only on that portion.

David Lang

The simulator in GC presently plots the intended path as calculated from the gcodes sent to the firmware and the actual path as derived from the current machine coordinates reported by the firmware. Where would taking account of chain sag or tolerance be applied?

1 Like

My maslow needs to pack up small and move to a remote build site without AC
power. A CNC mill might do that, but the rails or ball screws could easily be
bent in transit. Chain doesn’t care about potholes, waves, or rented help.
Everything including spindle runs off a battery and ATV charging system or PV
panel. Packing full sheets through the woods is tough so quarter sheets will
mostly be used.

so far so good

I cannot burn up full sheets trying to calibrate.

we do cuts with the bit to make measurement easy (but not that many, so you
don’t loose a lot of the sheet)

but you could use a v-bit or marker in the router (you need to do it ‘in the
router’ because switching to something else to hold the bit will change the
weight of the sled, and therefor the chain sag)

I am using
the maslow build to increase familiarity with hardware I already own and use
in other robot builds, and which I have a use for on site after maslow has
served its purpose. 300w motors, 64:1 planetary gearboxes, analog encoders,
very nice CAN motor controllers with integrated encoder readers, limit switch
inputs, and profile follower mode.

note that you really do want to have gearboxes that cannot be back-driven, you
want to be able to avoid having to reset the sprockets and chains every time the
maslow micro powers down

I do not have a mega, and prefer not to
learn yet another micro. I do have several Teensy and prior to maslow was
toying with the idea of implementing CANbus on them. This project provided a
plausible reason to tackle that.

There are a lot of us who would like to see things become more portable to
different boards. The arduino is common, but it’s really a lousy micro.

The increased speed and features of teensy,
the bigger motors, and the parallelogram chain theory make this a platform
that could test the limits of Maslow.

I think the parallelogram chain combined with the pantograph arms could be a
very interesting thing, however I’m not sure that it will really make things
work (we should open another thread on this topic and try to find holes in it.

Other things I’ve described are ways I
would personally like to use maslow. All that combined equals the need for
custom firmware. If going custom anyway, it makes sense to modularize. I
wasn’t going to expect the community to contribute all that, I would have to
do it myself. That means learning how the existing code works. So, I’m doing
that and contributing back what I learn in the process. I have received a mix
of very kind help, encouragement and … something else which I don’t really
understand.

Two approaches here.

  1. take the existing maslow firmware and try to learn and modify it.

  2. take something else (i.e. grbl, a much better codebase) and add two features
    to it

2a. the ability to drive a motor/encoder instead of a stepper

2b. the triangular kinematics (or possibly your parallelogram variation on it)

Also, Ground Control has (what should be) the same kinematics logic in it, but
written in python instead of C, it may be easier to understand (or at least, it
has different documentation, so some parts may be better documented there)

David Lang

There are two simulators in GC

one that lets you pretend you have a maslow attached when there isn’t one, I
think that’s what you are talking about

But there is a different one that lets you introduce deliberate error and plot
out how that error would affect the position, it plots where things should be,
and then (in a different color) where the maslow would actually cut with those
errors.

It allows you to add errors for top beam height, motor spacing, chain length,
etc.

The ‘Maslow Calibration Simulator’ allows settings for ‘chain sag correction’ and ‘right- and left-chain slipped links’ in decimal values of links out to hundredths of a link. Those wouild show what you’re after, wouldn’t they?

1 Like