I have been working on a new version of my FlexIO program for quite some time new, which has a lot of new features in it including use of wXwidgets for the GUI interface, better accuracy, and even more tools & control for the operator using it. This week I have finally began connecting stepper motors to it, and doing some real motor experiments.
There have been other significant improvements to the program as well, especially on the controller side. It is still using the Parker 6K4/ZETA4 Combo, only now with the new code the communication between the hardware and the controller is much more effective. It also does not need such a high end PC to run, as now there is no DirectX requirements, there doesn’t need to be any high refresh rates. This was a problem with the MicroATX computer used on Joshua, and a problem of the old program anyways. We all do crazy things when we have very little time to complete a project 🙂
Now that the new program is going through the final paces of it’s hardware testing, I hope to have this finished and out of the way within the next couple of weeks. I have a lot of other projects building up that I need to work on! Click on any image to see an enlarged version.
In the above picture: On the left are 3 ZETA83-135-MO Parker stepper motors, each connected to a ZETA4 controller box (the 3 stacked units to the right of the motors). These are then connected to the Parker 6K4 controller box (the large box to the right of the ZETA4 units, with 4 red LED’s on the top) which controls the motor’s movement. The 6K4 is then connected to the PC via an RS-232 connection, which receives instructions from FlexIO. During the development process, laying the motors out flat like this is a good way to test the motor communication & the programs ability to switch between motors and steps accurately and smoothly, without damaging any real hardware in the event that a problem might occur.
Screenshot of the current program interface for setting up the cable being processed:
Added a basic module to the new FlexIO program this week to assist in detecting moved XYZ tables. A common problem I faced was after a drawing had been created for a part, the actual part itself had been moved in virtual space. Then when the bend file had been created, the tables were completely different because of the move. Because of this, how to correctly determine if the table is actually correct, or if there was an actual geometry change in the design that had been overlooked?
The module I created just looks for simple X/Y/Z direction movements, it gets a little more complex when looking for parts that have been rotated in 3D space, so the model doesn’t look for that yet. It works by asking for the first row of coordinates from the drawing, and calculates the differences between the X/Y/Z in the bend file. If its just a case of simple movement, the offset is applied to the remaining points and the new table when updated will then identically match the drawing (if there is no geometry change). If you start seeing some points being a little off, you can check in CAD to make sure there is no rotation, and put the difference to being a design change which requires the original part designer to submit a revision change.
It’s a start, and saves me a lot of time when verifying a large number of drawings at one time. Still lots of other verification code to add to other areas of the program 🙂
I have finished working on my 3rd CNC bender, named “Sir Clive” after the great Sir Clive Sinclair. He received a complete refit and various other components. Details of this hardware/software project can be viewed at this link:
You can also read about the custom software I wrote to power the machine, named FlexIO, at this page:
This project has been a lot of work, and now it is ready I can finish some other projects. Thanks!