Articulated is just another way of saying 'jointed' so I would submit that a 4bar is a specific type of articulation . . although there are numerous types of 4 bar arrangements, so I would then use the term 'specific' only in a general way. How's that for an oxymoron?
I think the distinguishing characteristic would be the independence of motion of the various arms in the system. In a 4-bar, there is a fixed relationship between them, regardless of position, as the arms are pinned together at the pivot points. If you know the position of any one of the four arms, you know the position of all of them. To me, at least, an articulated arm implies having two or more independently controllable arms connected together, so you need multiple data points to know the position of the business end of the arm. Semantics.....
There is the answer. I have not the time nor talent to create a protocol, so I shall have to be satisfied to huddle with the rest of the masses.
I mean VERY simple, and easily modified/extended. If you'd like to see what it does, I'd be happy to fill you in. The protocol can be used as-is, with the specific "command set" defined by just changing a few very simple files. It's partitioned so the command set can be changed without touching the underlying "routing" code, and the hardware-specific parts of it are isolated in a few files, so the hardware platform can be changed quite easily, to move it to another MCU. I had to do this, since the same base code must be able to run on both the KFlop and the Arduinos. The only downside is this also force me to write it in old-fashioned C, rather than C++ or some other modern OOP language, which would have made the code a lot "cleaner". But, I did it in a pseudo OOP manner, so it's still quite easy to follow. And, again, the only parts you'd ever need to mess with are really dead-simple, and just have to do with validating incoming messages, and actually executing the commands. All the housekeeping of the actual "protocol" is handled by the low-level code, which neither knows nor cares what the platform is, nor what the messages actually contain, or what they actually do - it just makes sure they get where they're supposed to, and that valid responses find their way back to the initiator.
I'm looking to get rid of a USB smoothstepper and early reports on the new Ethernet version were all good, but now it is starting to look a bit like the earlier incarnation with problems going unfixed for extended periods. Kflop seems to be on top of things and responsive to questions.
If you'd like to try one, I have one (and several USB ones) I'd be happy to loan you.
On topic, of particular interest is the Kflop is extensible and may be a better portal for the ATC operational data than trying to communicate with MACH. I like the idea of having Kflop orchestrate separate CPUs which each have their own process to control. Kflops user code interface is where I would seek whatever advice you might be willing to provide, but the prerequisite of course is to have the Kflop.
To that end, initially all I really need to hear is (regarding the MACH plug-in) 'It works' or 'It works except for this bug, that anomaly, this workaround, etc' (in which case I would pass).
Your endorsement would be enough for me to acquire a Kflop and invest some time in it.
On that basis, I would recommend KFlop without hesitation. Tom Kerekes, the designer, is readily available, and extremely responsive. He's already made several changes based on my input, and has always helped come up with a solution to any problem I've thrown at him. I usually get a response within hours. My only hesitation would be that the learning curve on the KFlop can be a bit of a bugger. But, I'd be happy to give you assistance, and get you pointed in the right direction, so you can largely avoid flailing around in the dark as I had to at times.
You could easily have the basic machine up and running within an hour or two after unpacking the KFlop. Adding all the ancillary features can then be done incrementally.
As far as stability, I'm aware of no problems with the KFlop plug-in, and certainly saw none when I did work with it, albeit briefly. I've never seen any problems raised on the Dynomotion Yahoo Group, which it the primary support portal. If you give me information on your machines configuration, I could probably provide sample code that would get you started with only minor modification and debug. Significant parts of the code I have on my machine might well work on yours with only minor modification. My homing and probing code (perhaps the most complex code, other than my pendant "driver"), for example, I suspect you could use as-is.
With the KFlop, you do have to write code for things that you get out of the box with Mach3. For instance, you have to write code to control the spindle speed, do homing, probing, handling limits, etc. Very simple controls like relay outputs for coolant, etc, can be handled without code, but things like a PWM-driven spindel require some simple C code to be written. But, if you're not doing anything exotic, this code will generally be quite simple, in comes cases only a few lines. If you're at all familiar with C, you'll have no problems whatsoever. But, if you want exotic, it can easily handle that as well. I've added some unusual capabilities to mine, but the code is still trivial. For example, I can re-program all axis parameters on the fly from the PC application. This allowed me to store all configuration data in a single XML file, rather than having some in the C code, some in the application, and some hard-coded. You can also do things like have the KFlop processor hand off lines of G-code to be executed by the CP application, which comes in handy at times.
The KFlop is VERY powerful, and almost infinitely flexible. Once you understand it, it's a truly wonderful thing to work with. As an example, the code to get my ATC working took, total, probably two hours to write, counting the several iterations as the hardware progressed. It stands right now at perhaps two pages of dead-simple code with lots of white space.
Regards,
Ray L.
Guest
Show Posts
I doubt I could even articulate that much swing.