Closed loop virtual machine - next level UGS

[Juanduino]

Description

Hi!

First of, great work on UGS.

I’m new to CNC, but do have prior experience with smoothieware on a PNP.

Since I’m in the process of building a machine, the obvious closed loop question has risen. UGS support several Gcode executors and each of them has support for several drivers, so implementing closed loop in the sender_layer seems like the appropriate approach.

Imagine having a dedicated quadrature encoder “controller” with magnetic encoders on X and Y axis (possibly two on Y axis for dual stepper support). This dedicated MCU (not connected to the executing MCU) should feed sensed tool position to UGS (virtual machine) in order to compare the Gcode path, to the actual sensed path. If a deviation is recognized, it means some steps are lost, and UGS should take proper action eg. Pause the job or correct the path.

By offloading the executing MCU, having UGS close the control loop, the user would be able to visualize if the desired precision of the machine is achieved with the current settings for feeds and speeds ( aka control loop).

In a sense this feature would run parallel to the job, just observing the recorded tool path, but should be able to take action if a deviant (from the planned path) is recorded.

Does such a plug-in exist already?

[Juanduino]

On the UGS website, it says “ real time tool position feedback”. What is meant by that? Theoretical position or actual position?

Having done some more research, I believe the above closed loop implementing could be achieved by using this library:

https://github.com/PaulStoffregen/Encoder

I’m not sure having 3 separate encoders (on a dedicated MCU) while writing the positions via serial/usb will work as expected, yet another experiment in the pipeline. It wouldn’t really make sense to implement, if we loose encoder pulses. Ultimately it depends on MCU speed vs encoder pulse frequency. I do believe it is important to have the encoders on the same MCU in order to synchronize the sensed positions.

According to the above lib. Doc. Page the teensy 2.0 (16Mhz 8bit MCU) has a maximum interrupt freq of 127 kHz. Not bad for a AVR.

If doing a feedrate of 762mm/min the stepper will rotate at 6.35 rps which translates to (6.35 x 4096) 26.000 changes in states (interrupts). This is using a 8mm pitch lead screw with a 4:1 belt gearing. Hmm 🤔 the SAMD21 runs at 48Mhz and it’s a 32bit MCU. The conversion from step/encoder pulses to mm could be done on the UGS side.

How often the encoder position should be sent to UGS I’m not so sure. It would be like points on the Gcode “line”, which will make it possible to catch those microsteps lost in action. If the machine has two Y axis steppers, then misalignment could be corrected, maybe during a brief pause.

From this lib. Git page it says that windows will accept a 8ms USB data transfer frequency.

https://github.com/abaelen/Arduino-Isochronous-USB

So, with a 762mm/min feedrate (12.7mm/sec) the dots will be 0,1016 mm. a part.

For resetting the encoders to zero position, one idea could be to have the stepper controller pull a pin high or low, since Isochronous USB is a one way stream. This should make the MCU go into programming or setting mode, so we can talk to it.

[breiler]

UGS have no way of knowing the controller position without the status being either polled or pushed somehow. So yes, with polling, the position will be obsolete in the sense that it may be 200ms + latency old information (slightly below the average reaction time for humans) which has sufficed for its purpose of setting up a job and get a rough estimation where the machine is relative to the loaded gcode model.

Do you mean that UGS knows the position based on what commands it has sent? No, the commands that has been sent and was ok:ed by the controller are planned for the future. UGS have no way of knowing when they will be executed. Neither will UGS know the current speed/feed of the machine to be able to interpolate where the machine will be between to commands.

I am not an expert, but I believe that you should try to close the loop much earlier than trying to integrate with a slowish desktop software. I think that this should be solved in the controller, but maybe even a stepper motor driver could offer a solution (for instance: https://github.com/makerbase-mks/MKS-SERVO42C)

[Juanduino]

I didn’t say it would be easy, maybe the graphic card should be part of it. Next level AI stuff. If anyone knows their way around coding the program, I will be happy to make the pcb with a SAME51 MCU. I will most likely do the experiment anyways, since it’s awesome and becouse I need to know if my two Y axis steppers are synchronized. The SAME51 should have some overhead for the interrupt frequency compared to SAMD21 and I have a few on hand.

[Juanduino]

You do have good point with those Stepper servo add-on’s. They do claim to run smoother. I guess the only reason for combining the encoders would be driving down cost.

[Juanduino]

That said, I’m not sure which encoder they use. Maybe the advantage would be to use a top shelf encoder while maintaining a low price point. On the other hand, if those servo-stepper pcb’s had a TMC5160 with quality FETs one could increase the voltage and current significantly.

[Juanduino]

Principle of operation:

The SAMD(E)51 USB has DMA access to RAM, so positions can be send without MCU intervention. This does require setting the whole thing up by writing to the registers.

The MCU has a hardware QDEC interface but not sure it can handle more then one encoder. The interrupt based encoder library mentioned should work without loosing pulse count.

Looking at the AS5147 magnetic encoder, it can go up to 14 bit (16384 steps / 4096 pulses per rev.) 12 bit is standard, so it will need to be programmed once to get 14bit resolution/rev. (OTP (One-Time Programmable) ) This encoder can therefore be used in a direct drive configuration w. very good resolution.

How the UGS plug-in should handle the data is another story. I imagine it should be similar to the Gcode simulator, in 2D for X and Y, possibly zoomed in on the polled position for highest possible resolution. Knowing the frame resolution, the plug-in should “visually” determine if the sensed (actual) path is on the gcode path.

This approach can also be used with linear encoders, which can sense backlash, but does have a hefty price for the magnetic strip.

[Juanduino]

http://www.java2s.com/example/java-utility-method/distance-between-point-and-line/getdistancetocenter-point2d-p-line2d-line-e2852.html

Hmm.. arcs would be a challenge.

I guess we know the center of the arc?

Maybe it can be done with math, the visual approach would perhaps be too flimsy.

https://www.varsitytutors.com/hotmath/hotmath_help/topics/shortest-distance-between-a-point-and-a-circle

So if the sensed coordinate is between two points representing a arc in the Gcode, run the arc math to get distance to Gcode path.

Maybe you can even extrapolate the feed rate if the data is coming at a fixed interval? You are the expert 😅

The Z axis should have its own 2D window synced with X and Y to enable 3D carving.

[breiler]

The controller will follow the path laid out by the gcode. That is its purpose and why we use a single MCU for the controller.

The result from the gcode is a machine position (among other things) which is the controllers purpose to keep track of, I agree.
And instead of making the controller more robust by giving it the ability to fetch measured position data, you propose that UGS should second guess the controller which doesn't make sense to me. UGS can not do anything if it finds a discrepancy other than aborting the gcode program as there is not a way to fine tune the controller position (at least for the controllers that I know of).

From my point of view, your solution is over complicated. You have suggested using dual USB serial lines, fetching measured data points for figuring out if they matches some state at a given time of a gcode program (with AI?) and a new plugin for handling and configure this in UGS.

In my world all of this could be replaced with a real time check at a strategic moment in the controller - does the estimated machine position correspond with a measured real world position.

These are just my opinions, you might find someone else here that is willing to experiment with it?
Either way, I can recommend a discussion with the FluidNC-team who are way smarter than I, and can maybe give some wise thoughts.

[Juanduino]

UGS can not do anything if it finds a discrepancy other than aborting the gcode program as there is not a way to fine tune the controller position

That would definitely be a challenge, to make small adjustments/corrections on the fly, during a job. It would involve some latency, and I agree with folks saying that hybrid-servo-steppers does not have that latency. But then again, those hybrid-steppers does not know the tool position, just if that motor lost a step during a move. One argument could be, that streaming the encoder_coordinates into UGS (closing the loop) will make the user aware of that particular machines strengths or limitations. It would give some certainty while running a large complex job, which open-loop doesn’t give. It will possibly involve a new command_type eg. “ +2 steps on X-axis”

Regarding the USB/serial I believe it should be dedicated USB-full-speed packets holding the entire coordinate.

[Juanduino]

you propose that UGS should second guess the controller which doesn't make sense to me

Second guessing the controller would assume that the controller has some real world knowledge about the tool position. In my view the system (UGS) would tell the controller “dear controller, You are not on path” or “OMG! Pause the job! You are 0.5mm off course and has way too high chip load”.

Let’s do a theoretical thought experiment: The tool is pushing into aluminum with a conservative ship load while rouging. Still it somehow losses some steps in the process. While it is pushing that same direction the chip load will be less of what it should, which does not pose a threat, but as soon it changes direction, since the controller is off target, suddenly the chip load is higher then is should be and now it looses another step. This is just to illustrate the accumulated effect of small mishaps.

Comparing what I propose to hybrid-servo-steppers is like comparing apples and oranges. Both approaches is closed loop, while one has a emphasis on hardware (hybrid steppers) the other is more rooted in software with a minimal hardware footprint (lower cost). Well that may actually not be true for prototypes.

Looking at those Chinese hybrid-stepper add-on you linked to, I’m amazed at how cheap they are, but I also see a lot of components. If the same end goal can be achieved by code (software) the climate footprint will be much less, especially for people who already has a controller with stepper drivers in a open loop configuration.

[breiler]

I wasn't planning to entertain this discussion any further since I'm not going to develop anything on this (not ruling out if anyone else interested though).

I think that the idea is cool, implementing a cheap closed loop system. But I think the solution for implementing this is backwards and you are mixing up the responsibilities, you even said it yourself:

In my view the system (UGS)

And I am quite certain that you would get the same response from any "sender-project". But by just rearranging the responsibility of the different components in your solution you will get the same effect, cheaper and will be more simple.

Since you like thought experiments, here is some of my random thoughts surrounding this:

• There are plenty of different controller firmwares and at least twenty times as many gcode senders. By simply implementing this in UGS you are cutting your user base to just a fraction. Your idea/solution will get more traction if you implement this in the controller. It is still just software and you can use your cheap hardware. Then there is no need to modify existing gcode senders which will increase the potential user base as it will not depend on the sender implementation. New clever status reports from the controller can still bring you the messages such as “dear user, You are not on path” or “OMG! Pause the job! You are 0.5mm off course and has way too high chip load” or whatever...
• This solution is not a silver bullet for handling misaligned machines. You are only talking about missing steps from the stepper motor. What about backlash? So without measuring the actual position of the tool or gantry, your solution will still only get a theoretical position of the tool.
• If when using your solution running a job with UGS and it has adjusted the position of the sent gcode. What should happen when the job finishes? The controller still reports the wrong position, so running a new job could be dangerous. If the responsibility of the machine position lays on the controller it would either report the adjusted real world position or that the position is screwed up.

[Juanduino]

What about backlash?

From my understanding backlash will not effekt the final result if one does a rough pass and then a final or several detail oriented passes.

Linear encoders would be a step up I guess. Maybe that should be my focus. Anyways, thank you for your feedback and eyes on this. Keep up the good work!

[winder]

You might be interested in klipper. I understand that it works with step planning for one or more controllers on a computer and the controllers just need to deal with timing the steps properly. https://www.klipper3d.org/Features.html I'm not sure what this sort of scheme has to do with UGS. Maybe you could implement a klipper mode? Will.

…

On Fri, Aug 26, 2022, 11:41 AM Juan-Antonio Søren E. Pedersen < ***@***.***> wrote: What about backlash? From my understanding backlash will not effekt the final result if one does a rough pass and then a final or several detail oriented passes. Linear encoders would be a step up I guess. Maybe that should be my focus. Anyways, thank you for your feedback and eyes on this. Keep up the good work! — Reply to this email directly, view it on GitHub <#1967 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA6URPG57I24UOYMR5PBWLV3DQTDANCNFSM57L36T3A> . You are receiving this because you are subscribed to this thread.Message ID: <winder/Universal-G-Code-Sender/repo-discussions/1967/comments/3484993 @github.com>

[Juanduino]

Yes! That looks fully modular. Like sub_drivers in openPNP. Cool that they are working on motion sensors. I guess one would somehow time_stamp the position for Klipper to use in driving the steppers. That would move the closed loop closer to the machine. I just have no clue as to how good it is compared to eg. Smoothieware. If it really works, those hybrid-stepper drivers could act as sub_drivers. Maybe this calls for a modular hybrid-stepper version w. headers for typical pololu format drivers and maybe a revival of the Bigfoot. Another approach would be constantly updating the tool position in smoothieware.

Edit: As a side note, the Gcode for offset already exist:

G92 is typically used in two conceptually different ways: as a "global coordinate system offset" or as a "local coordinate system offset". The G92 set of commands includes:

G92 - This command, when used with axis names, sets values to offset variables.
G92.1 - This command sets zero values to the G92 variables.
G92.2 - This command suspends but does not zero out the G92 variables.
G92.3 - This command applies offset values that have been suspended.

http://smoothieware.org/g92-cnc

In praxis, this command will bump the workpiece origins to match the lost steps (or motor physical position not in sync with controller theoretical position).

[Juanduino]

I suppose, but not 100% sure, that the new G92 offset also applies to moves in the controller buffer? If so, it will cut down the latency significantly.

Edit: Took a look at smoothieware planer code, and I’m pretty sure the planed moves will execute before changing the origin with G92. What a drag ☺️ A workaround would be to raise a flag and redo the look-ahead if a G92 for X, Y or Z is recognized.

[Juanduino]

Hi @winder

Time has passed, and I think I’ve found a viable solution, that could work with UGS.

In the search for a S-curve planner algorithm, that can work with SimpleFOC, closed loop field oriented control, I found a paper describing a math-concept for that. The math checks out, and I’m able to calculate some pretty smooth trajectories.

here is the dev repo: https://github.com/Juanduino/S4_CurvePlanner/tree/main

My initial focus was just getting this working with OpenPNP, which has several options for the level of Gcode control. The simplest being just point-to-point commands w. M400. Naturally we can still adjust jerk, acceleration, feedrate for individual tasks, like nozzle change etc.

So how can this benefit UGS. Well the math-concept does not end with point-to-point moves, but actually goes into multi-axis/joint synchronization. This means, we can place part of the algorithm in the UGS Gcode parser and send time synchronized moves to independent sub-nodes (eg. a USB connected motor controller running SimpleFOC). On a CNC or laser-cutter etc. having the option to use open-source servos (real closed loop control) should provide a substantial upgrade. Especially for larger system, outside the range of stepper-drivers.

Theoretically the math in C++ can be integrated through a DLL in UGS or it can be ported to Java, I’m not able to discern if running C++ in a Java application has drawbacks?

What is needed:

In order to connect each sub node, either through serial or dedicated USB device, this should be an option in the GUI.

Naturally, if selecting this S-curve mode, it should use the S-curve math. According to the paper, they did 100 trajectory planning calculations in 1.5 milliseconds on a PC.

There should be some level of time-syncing between the host and the nodes. In essence it is what Klipper does for stepper-drivers, calculating steps, times etc. but with a focus on closed loop control, which will open up the whole concept to potentially more powerful BLDCs as well. The math-concept does not mention time-stamping the commands, and each trajectory calculation does involve timing the move. When syncing the moves, the algorithm should first calculate each axis/joint for the given move, then the longest move is selected and the rest is scaled to match, using a scaling factor.

The motion handling will be on the MCU. Either all the trajectory planning should be on the host-side or just the syncing and the planning then happens on the MCU with the scaled jerk, acceleration and feedrate/velocity.

[Juanduino]

[Juanduino]

http://usb4java.org/quickstart/javax-usb.html