Probably going to be a longish entry, at least video wise.

One of the things that'll improve usage, bit life, finish quality etc is having the computer control the speed of the motor. As i mentioned in the last log the flashcut can't do it without an upgrade, given a crappy HID numpad with a cover is about $500. I didn't want to ask. I started to look at Mach3, discovered Mach4 pushed off backlash compensation to the drivers boards I thought I'd try another way. Before I go on, CNC people are the religious types, like car people. Backlash is bad, can do terrible things, but being able to correct small amounts of it for certain things is useful to me, it is a tool and like any tool it can be used incorrectly, but I still want the option to do it.

All I had as an output on the FlashCut box was 1/0 low voltage digital on the controller side, and 0-24v or measuring resistance on the VFD wasn't a whole lot to go on, sure I could buffer the signals but that is still on/off , can't make a DAC since not enough control of the lines.. Really basic stuff.

I'd picked up the Automation Direct RS485 to USB adapter that allows me to connect to the VFD to program it. The software doesn't control the speed just the programming. I took a look around and didn't see much available, it is modbus which is fairly common in SCADA etc. Never used it before, I believe the internals of the FlashCut might have some modbus going on. I knew other people had used the modbus support in Mach3 so it can be done, but how to the flashcut gcode controller software to the modbus of the VFD.

I poked around and switched on the 0-10V display of the RPM in flashcut this pops up a slider and a text input box to allow you to either type in the RPM or move it up and down, so i figured all i have to do is read that out and we've got the RPM value.

This is what the loopymind HAD DXF logo looks like in flashcut

So at the bottom in the middle is the RPM edit box. This is a generic windows GUI element we can read it from somewhere else, consider it like a file system. It stores named objects that contain data we interpret, so we don't need to know the location of the RPM variable in FlashCut's memory space, we just need the GUI's data which means we don't need to hook or mess with FlashCut at all, which is desirable for something like CNC..

I'm using Microsoft Visual Studio C++ 2016 here, but it is mostly the same procedure for the last dozen or so versions.

In the development tool-set there is something called Spy++ that allows us to watch windows messages and interrogate the GUI, very useful tool. It's usually on the Tools menu of Visual Studio or you can just run it from the start menu.

Run it and you'll get something like this :-

We can even see this post i'm writing now listed as a window. These are a list of the Windows in the GUI, Windows (the OS) treats a lot of things like Windows(the GUI) so you can see tool tips (the little popups that show when you hover with the mouse),, there are some hidden apps/windows, Mostly visual studio windows here.

We're going to use the Window Search feature to find the FlashCut window handle, so run the application you want to take a look at and then in the Search menu of Spy++ use the Windows Search popup.

Apparently I also some allergies going on.

OK, so now we know what we're looking for there is a Window class called "Edit" which is the name for a standard windows edit box.

We'll also need a library to chat to the modbus, I found libmodbus and made some windows style changes for it and added a 64 bit version of it, that is on my GitHub https://github.com/charlie-x/libmodbus it does have some specific changes for window, i changed the f/printf's to switch to the debug message system windows uses and started to remove the errno to their version since i don't like the idea of one variable for all errors, and a few changes for 64 bit and some of the newer API's. It is forked from the original.

Next we will fire up Visual Studio and start creating the application GUI, probably better to watch this one full screen, not sure why HAD.io inline has such a teeny window for videos.

So the next steps are to track down the values from FlashCut and reflect them in our GUI, for that we'll go back to Visual Studio and start adding code.

This video goes through finding the window, capturing the values and reflecting them in our UI, this time with audio !

We've pulled out all the information we need, and no need of reversing or disassembling at all. We're not even really looking inside FlashCut, just querying the Windows GUI. This technique works for most MFC/Windows apps.If we've learnt anything so far, it is SUCCESS has two Cs !

In part 2 I'll connect up libmodbus and start talking to the drive itself.