VS code about iosender

[terjeio]

VS Code is just an editor it seems - AFAIK it cannot be used to build the app as it is written in C# (unless you can set up a toolchain for that). Thus I believe Visual Studio is required, 2015 version or later. However, I am about to release a binary, if you can wait a few days then you do not need to download and install Visual Studio.

[jschoch]

I tried to get the c# and .net components working with VS code but I just don't know enough about the project.json, .sln, or .csproj differences and nuances to get it to build. I did get CNC-Core to build but it had some esoteric issue with CNC-Controller .net framework version issues and i gave up.

Looking forward to the binary.

I'm hoping that my nitpicks are already solved. I'll list them.

1. jogging sucks. UGS platform sometimes tries to jog like 5meters when you change a $$ parameter. BCNC is all kinds of jittery.
2. keyboards suck for jogging mostly. a num pad helps but i'd prefer dedicated jog interface with an MPG that can set feedrate based on the MPG speed/acceleration. dedicated keys are a must for fine movement. feedrate select should be quick and require little thought.
3. keyboard focus in UGS has broken many endmills. BCNC seems to handle this better.
4. probing routines are amazingly lacking. I wonder why? UGS has a decent inteface for corner detection but BCNC is opaque to me so far. BCNC has very good auto leveling and center finding but you can't detect on a cylinder. Seems like a common probe you'd need.
5. UGS's configurable UI is mostly nice since I can move windows around, resize them, and hide what I don't need. BCNC is much more modal however you seem to need to move between taps during a single operation. Autolevel for example requires several mode switches to finish.
6. BCNC message are completely non intuitive. Save probe data doesn't do what you'd expect and it doesn't seem like they are open to changing the UI so....

[terjeio]

1. no comment

2. I use keyboard jogging all the time, I like the Mach3 implementation with modifier keys - for step, for faster. So that is what I implemented. $50-$55 to set distances and feedrates. The $50-$55 settings are not used by the standard firmware but rather by the sender and keypad plugin to provide a common place for these parameters. A few days ago I was considering moving handling of these settings to the core if the keypad plugin is not added to the firmware, perhaps I should do that. If you want to use a MPG pendant with ESP32 I will have to add a secondary serial input stream to that driver too, or do you want pendant support in the sender?

The MPG controller I've made has buttons for jogging but issues "normal" G1 commands from MPG encoder movements - both speed and distance is derived from the encoder.

3. Keyboard focus is problematic in windows apps, I know... Be warned that I've had a couple of instances (1 or 2) where jog cancelling did not work and I had to hit the estop. Currently I disable the whole UI while a jog is active in trying to avoid this, I have a feeling that the WPF framework is a bit fuzzy sometimes.

4. I have not implemented any probing routine in my sender yet, open for input. I perform manual touch off on my Mach3 controlled router.

5. Configurable UI: not (yet) available. Since I've switched to the WMMW coding pattern this should not be too hard as the UI is decoupled from the underlying logic. I've had no need for autolevelling so that is not available. There is some automatic UI configuration based on what functionality grblHAL reports back: lathe mode wizards, SD-card file list/execution (currently very simple), tool table offsets etc. These are all presented in separate tabs taking over the whole UI area. The 3D viewer is currently only available in a separate tab, this should be made available in the main tab.

6. I am open to changing the UI, looking forward to input...

[jschoch]

I'd like to take a crack at a pendant that does not rely on keyboard HID at all. I have not yet though about the best way to implement it. My previous attempts used serial man in the middle but it was not 100% stable due to the known $j issues and my own c/c++ ineptitude.

regarding #3 this is my biggest gripe with UGS since you want to focus on the machine and not a textbox. i've had 1 too many crashes because the textbox was getting input from the numpad and I end up moving 10x what I wanted.

for #5 as long as you don't often have to change modes while in a single operation and the workflow makes sense this isn't a deal breaker. It also seems like there has been quite a lot of work to standardize autoleveling in the 3d printing world and that work should be reusable. On my PCB mill I can mill .6 mm pitch pins but autoleveling is a must. It might be something I can contribute.

finally, I believe I will finally be able to get back my larger lathe which I want to convert to CNC. How's your spindle sync implementation been working? My small lathe is setup with a centroid acorn board and I don't think I ever want to do manual threading again yet I hate their software.

[terjeio]

A binary build has just been published.

For the MPG I made for the lathe I went for man on the side (?), using input from an additional serial stream. This allows me to use the lathe without firing up the PC and is what some of the grblHAL drivers support.

It would be nice if you could help out with autoleveling. Are probing the PCB within the bounding box derived from the gcode or do you have to specify this manually? Distance between probing points? As I made a laser based PCB exposer I have never looked into autoleveling, more to learn...

I hope my UI layout is useful, I do not like a large cluttered UI so that is one reason to split it in tabs. Looking forward to feedback...

Spindle sync is moving moving slowly forward, I've got a VFD and and switched to a washing machine motor (!) in order to get more torque. The BLDC motor I tried was a joke, Chinese specs are not to be trusted. I need to update the z-axis to a ballscrew, looking for a second hand one from Korea. The original has a whopping 1.5mm backlash...

As for the implementation I have tried closed loop RPM control in addition to positional feedback, but ditched that for now a few days ago. A test I did with only positional feedback gave a PID errors in the range +0,005mm to -0.009mm for the last pass, which I suspect is far less than what the current z-screw is actually capable of delivering. I would guess the error range is within what is acceptable, but I am no machinist so I really don't know. The nut fitted well enough.

Are you considering ESP32 for the lathe too? I do not know it that is a wise choice, the "meditating guru" has a habit of occasionally waking up and spoiling the fun. I found out recently that accessing the FPU in an ISR crashed the processor... Since I am currently using floating point calculations in the PID loop and that runs in an ISR I guess it has to be converted to use fixed point calculations - perhaps easier to use a processor that has a FPU that behaves better. The ESP32 FPU is not known to be particularly fast either.

[jschoch]

Excited to test the firmware!!!

BCNC has a feature that establishes the autoprobe margins from the gcode. You can then specify the size of the matrix to probe e.g 4x4 or 5x3. It then runs the gcode through some preprocessor in real time to adjust the Z. You can also save the matrix and reuse it but I don't think this is what you actually want to do for a PCB. I have not looked at the different 3d printer implementations but klipper firmware seems to support quite alot of different modes. If python could be integrated into the sender then that could could be reused as well as BCNC. I have very little python experience, most of my last 5 years of hacking has focused on Elixir and Erlang.

regarding the motor i'm using a sewing machine servo and parting and threading are no problem. The problem is the lack of a reverse switch, but this can be fixed with a double throw 3 pole switch. The model i'm using is the consew CMS3000. I also noticed 220 sewing servos on ebay for real cheap ($70 USD) yesterday, they are intended for sewing leather so they have extra low end torque. If the controller firmware could be hacked or the righ pin found they'd make a great lathe motor. The taig guys use them which is how I found out about them.

The centroid acorn CNC and the ELS firmware's i've looked at don't really try to keep the RPM constant. They just keep the movement in the right place based on the RPM. So if you load up and slow down the z slows down the feedrate. I also don't think you need fp math, there is a russian ELS running on the old mega and it seems to be working for many folks. I'm also not sure PID is what you want, ignoring the RPM seems to simplify everything.

[terjeio]

I am not too keen on adding another language in the mix - it complicates distribution. I prefer converting to c#. Probing is the first easy step so will start there. I took a quick look at the BCNC code yesterday but was not able to locate the file where the height map is applied to the gcode. It would be great if you could point me to the correct file(s). Perhaps it is easier to find in the clipper codebase...?

I've seen the sewing machine motors before, will take a look at them again if the washing machine motor lets me down. FYI my port for ESP32 already includes the option for adding an I2C I/O expander - I use this for a motherboard I made for my CNC Bosterpack in order to overcome the lack of gpio pins.

Ignoring the RPM is what I do now, I use input from the encoder to calculate the z-position, and then use that to calculate the PID error signal. I modify the number of step pulses per step segment in the driver layer based on the PID output signal. There are surely other ways to achieve sync, but I am not sure I want to move the sync code to the grbl core as I want to keep that as generic and "clean" as possible. Littering the core code with a zillion #ifdefs makes it hard to maintain and one may end up with a lot of variants. The grblHAL core is common for all processors, functionality in a driver is generally communicated to the core via the HAL interface, not #defines. I'll like to keep it that way.

I went with PID since that is what linuxCNC uses, and I selected MSP432 as the initial target as is has a FPU, plenty timers and gpio pins.

Anyway, it could be interesting to look at other ways to implement spindle synced motion. Where to add it to the codebase could well be the tricky bit. Perhaps a good idea to start a issue thread over in the grblHAL repository?

Thank you for all the input, much appreciated!