Machsupport Forum
Mach Discussion => Mach4 General Discussion => Mach4 Videos => Topic started by: DazTheGas on May 16, 2015, 02:09:04 PM
-
As promised heres a very short vid on an arduino being used as a keyboard to control mach4
https://youtu.be/8PV-OlcmqH4
DazTheGas
-
Nice! Wish all videos were as well done.
-
it was a bit weird trying to sync 2 camcorders and screen capture at same time.
DazTheGas
-
Well done. Both the interface and the video.
The first time I had occasion to mess with the keyboard plugin was in the current 2441 release and it is broken :( however, I read that the plug-in from the prev version can be brought forward and it works. Have not tried that yet, but I have noted that the pre-defined jog entries on the setup screen do not include an explicit JogOFF command, so it must be built in to a macro that is actually what the plug-in is calling.
That might explain a user report that MACH4 will imitate a jog while disabled, but the jog does not stop. That would be a nasty bug indeed. Are you experiencing this?
Couple question, if you don't mind;
Are you using the Arduino driver to talk to the plug-in via a COM port or are you emulating a USB device?
The touch screen looks like a 4D. I found it difficult to choose between the built in graphics library and the Arduino library. I was not expecting two vastly different methods and the need to choose one over the other. Each has advantages and disadvantages. Which did you choose and why? I have decided against using the touch screen, but the dual methodology is still a point of curiosity.
-
Well done. Both the interface and the video.
The first time I had occasion to mess with the keyboard plugin was in the current 2441 release and it is broken :( however, I read that the plug-in from the prev version can be brought forward and it works. Have not tried that yet, yes you can Daz sent me copy from the last version it fixes the problem its in the last place we spoke
but I have noted that the pre-defined jog entries on the setup screen do not include an explicit JogOFF command, so it must be built in to a macro that is actually what the plug-in is calling.
that was talked about in the mach yahoo page
That might explain a user report that MACH4 will imitate a jog while disabled, but the jog does not stop. That would be a nasty bug indeed. Are you experiencing this?
the M4 scripting manual has the correct code to stop that happening with a external button with a small change when I have it bang on I will post it I don't get my machines computer back to the end of the week Daz have you worked it out save me re-posting
-
The one in the video is an arduino leonado emulating a keyboard thus connected by usb, this was purely to show that the keyboard plugin can be used if required. And they do a Ethernet version.
At the moment I am designing a shield that connects to the ESS and uses the input and output signals and uses a mega chip to run the 4D screen and external functions, this wont be used for jogging as the screen will be mounted in the case, but could be used for homing and moving to preset points etc. All signals will then be sent and recieved through the ESS, and as something comes up that is required I dont have to wait for someone else to implement it. I have been testing out with great success in the PLC script a form off sending out a series of output signals and the mega displaying something (er a bit like binary if you like). will keep you posted on that.
Yes the keyboard plugin does have its drawbacks, only this morning mach4 was in the background whilst I came to have a look at this board (did you and daniellyall stay up all night??) and went to reply to a thread, DAM!!! the 4 keys were still assigned to jogging from yesterday and the machine started moveing, but has been tested using the signal inputs not keyboard with success, they must use internal mach4 functions.
Although even that dont put me off the keyboard principle, its all down to what you can achieve in the PLC script, IE most things are safer to run in the PLC a simple function, if wxlua screen lost focus then dissable keyboard plugin etc.
DazTheGas
-
The one in the video is an arduino leonado emulating a keyboard thus connected by usb, this was purely to show that the keyboard plugin can be used if required.
My question was not clear. The Arduino typically uses the USB physical connection to the computer, but it is not a native USB device. When it is plugged in, the USB buss discovers it and a driver loads which then emulates an old style serial COM port. The conversion is done on a single chip, usually from FTDI, but Atmel now makes a similar chip as found on the newest MEGA (and I think also the DUE).
It is my understanding that the Arduino can become a native USB device. I have not done this, so I know little about it, including if it requires a separate 'shield' like Ethernet.
So to ask the question another way, does the keyboard plug-in talk to a COM port or only native USB devices (typical keyboard)?
And they do a Ethernet version.
An Ethernet version of what? The Arduino or the plug in.?
Yes the keyboard plugin does have its drawbacks, only this morning mach4 was in the background whilst I came to have a look at this board (did you and daniellyall stay up all night??)
Can't speak for anyone else, but I am a consulting engineer and my hours typically match the location in the world where the project is. I've tried getting 20 other engineers on-site to teleconference with me at 3AM their time, but so far, not much luck with that . . . :D
Although even that dont put me off the keyboard principle, its all down to what you can achieve in the PLC script, IE most things are safer to run in the PLC a simple function, if wxlua screen lost focus then dissable keyboard plugin etc.
I don't know much (actually nothing at all) about the keyboard plug-in, but certainly it is another avenue into MACH that does not require programming, so that's a good thing. I am not, however, a fan of USB.
I think it would be correct to say that fundamentally there are three ways to get stuff in and out of MACH4, those being a plug-in (usually only made for a specific device), plugging into an actual or pseudo screen button and launching the desired actions from the button (either by 'action macro' or scripting), or via the PLC script. BTW, 'action macro' is my own term. I don't know if there is an 'official' name for these guys, but the term 'action' is used in the button setup, so there you have it.
For those who know how to program, the PLC script is extremely flexible and powerful. The MACH team recently added a separate thread (processor thread, not forum thread) dedicated to running the PLC script, so there is almost no practical limit on what you can run in there, and there seems to be access to everything from there.
-
Daz sent me copy from the last version it fixes the problem its in the last place we spoke
I have since moved an earlier plug-in forward and it *seems* to be accepting keystrokes in the setup. That's as far as I got . I really do not have a use for the keyboard plug-in. It is just a curiosity.
the M4 scripting manual . . . .
You have mentioned this 'Scripting Manual' before and I have not found such an animal so far. There are three documents that list the MACH4 Lua functions. Is there something else available?
-
I don't know much (actually nothing at all) about the keyboard plug-in
I am the same, I only know from trial and error when i was going to use the plugin, but after decided to make use of the ESS
An Ethernet version of what? The Arduino or the plug in.?
There is an ethernet version of the arduino.
the M4 scripting manual . . . .
Can I get a copy too ;)
DazTheGas
-
. . . decided to make use of the ESS
First, let me report that moments ago, I read a confirmation that the nasty jogging bug is either in MACH4 or the supplied keyboard plugin. That's not cast -in-stone, but it is certain that the problem is not being caused by the ESS.
My guess is the Keyboard plug-in, but that speculation, plus 5 bucks, will get you coffee at Starbucks :-[
It makes good sense to me to leverage the Ethernet connection and I/O that the ESS provides, provided you only need bitwise I/O.
There is an ethernet version of the Arduino.
Got it. Normally, I would not want to hijack a thread, but since it's your thread and you are using both Arduino and ESS, you may benefit from knowing that the Arduino Ethernet shield and the ESS get along nicely in the same sandbox, just in case you (or a reader) ever decide to put them in there together. . I ran them both simultaneously in the following configs:
*Each hardwired to the same computer each with its own NIC
*Thru an Ethernet switch with no other devices on the network
*Thru a full operational network with and without Internet access.
In all cases, there was no conflict. Notes:
*The 'default' ESS IP was not used in favor of the more conventional 192.168.x.x
*The Arduino shield was a genuine Arduino part with a legit MAC number.
Edit: Oops, forgot to mention the above has not been tested with the new ESS plug-in released recently.
-
Very handy to know.
DazTheGas
-
the M4 scripting manual is under manuals in the web site
-
After lots of research today I've ordered an Arduino yun in replacement for the Leonardo, it's got dedicated Ethernet and Linux bridged to the Arduino opening up a whole new avenue for communication between Mach 4 and external devices.
DazTheGas
-
After lots of research today I've ordered an Arduino yun in replacement for the Leonardo, it's got dedicated Ethernet and Linux bridged to the Arduino opening up a whole new avenue for communication between Mach 4 and external devices.
DazTheGas
You may want to also look at the new Rasberry, especially if you are going to use the processor based 4D libraries. It has Ethernet and a bunch of other stuff built in, can run Linux OS and has multi processors. My current product uses the Arduino MEGA and the next Gen (MACH3 and MACH4 TCP) uses the Arduino DUE.
The MEGA was pretty much maxed out and the only avenue to loading it more would be to implement interrupts, but I could never get the interrupts to work right on the MEGA.
In the real world, the DUE is about 5 to 7 times faster for typical stuff. For me the real highlights are the FP performance and also the DUE's interrupts work perfectly. I have added a LOT of load to the DUE and was anticipating (but not looking forward to) the need to move to the Rasberry, but the DUE is chomping thru everything without any perceptible slowdown.
-
My current product uses the Arduino MEGA and the next Gen (MACH3 and MACH4 TCP) uses the Arduino DUE
What libraries you using on the arduino to connect to modbus??
DazTheGas
-
don't forget about the Beaglebone Black! Now we are talking. Let's load Mach4 (didn't they say cross-platform?) on these little guys that can run full Linux. The Aurdrino Yun is good for comms as an interface to your host to which your requirement is for. But as a host, the Beaglebone can run full Linux...I think the Raspberry Pi does to. Mach4 in my pocket! w/ an MPG cape/shield. Fingers crossed on Ubuntu/ Mach4 platform. Mach4 needs to be a type of open-source API is paid for but the core code is available for customization. It would become LinuxCNC on steroids I bet.
http://beagleboard.org/black
-
The Arduino yun that I am playing with also run a cutdown version of Linux, plus able to run Python scripts, there is a bridge library which enables the Arduino chip to communicate directly to the Linux os, so I decided to use pymodbus for communication via tcp and have the atmel chip collect or send via the bridge.
DazTheGas
-
Dude, you are totally opening up a world in which we can program and use Mach 4 's core engine for customization on a very small footprint. You are beating me to it! haha! I'm glad. It's the love for the game right there. The experimentation and the excitement of accomplishment...plus the frustration, trial and error, and cost...but funk it. It's about learning, expanding our knowledge and sharing it. Mach3 boards have good Audrino threads in it too. You can start to see common themes and patterns. Once they are identified, it doesn't matter what language something is programmed in. How do you think people can talk five or six different languages? They are good at pattern identification and association. It's only a matter of time before Mach 4 is broke wide open and is truly customizable. I am not talking about cracking Mach 4. What I am talking about is the potential of Mach 4 to be a PLC interface that everyone can afford and tailor to their specific requirement. It's pretty cool actually and exciting. Knowledge, experience, skills, abilities...it is those characteristics we need to share. Other than selling our foreign competitors the licensing fees to our patents and property rights at minimal value while they turn around and buy US debt and resell their products from our designs at a higher value. But, it is cheap you say? How cheap does our investment in our future become? ....FML, i just went into left field. Sorry.
Keep on rockin Daz!
-
yah, I know. The PCB boards we are experimenting with are manufactured in China. I just went off the cliff there. Off topic and I promise not to bring it up again.
-
the amount of faster boards that are coming out almost make what don't you use, some of them are still a arm and leg to buy some are at a good prices a few of them will work with arduino code it would be good to try one of the faster boards using modbus
-
To add my two cents worth to the topic of board choices, I don't think there is an answer to the 'which board is best' question. Like the age old Chevy vs Ford debate, it is opene ended and always will be.
In my view the best board choice is application dependent. If you need an OS, and you have not the skill or time to be porting stuff, then it is wise to [purchase a board that already has an available OS that will run your software.
Really, processor wars are all fine and good, and dual or quad core processors are spectacular IF you have an OS that supports them or an appropriate compiler, otherwise they are essentially single core processor. The overall success of a given board in a given application boils down to what support chips you need for your application and which are integrated into the board. For example, there are no single chip solutions for Modbus (that I know of) and the calculations are integer math so that playing field is fairly level, however, there are a number of single chip USB, Ethernet, Bluetooth, and so on. Some Atmel processors (Arduino) have I2C built in as well as very fast high resolution (in the case od DUE0 A/D converters and interrupt controllers that are supported by available libraries.
My application requires a lot of FP math, so that is weighted heavily when choosing a processor, but I also need Ethernet and non-volatile storage, so integrated Ethernet and either EEPROM or an SD card reader is a distinct advantage. I do not need blue tooth, so that has zero weight. The next application might need blue tooth and no Ethernet, so the choice might be different.
Unless you want to spend the liion's share of your development time 're-inventing the wheel', available (and working) libraries for the functions that you need should be at the top of the list. Modbus is a good example of that.
-
what's up in the audrino/raspberry pi/beagleboard world with m4? I'll get there eventually....after I figure out Lua, then only to figure out Python or whatever these microcontrollers use, lol! it's all good... if I'm not learning something new, I'm wasting my time :o)
-
what's up in the audrino/raspberry pi/beagleboard world with m4? I'll get there eventually....after I figure out Lua, then only to figure out Python or whatever these microcontrollers use, lol! it's all good... if I'm not learning something new, I'm wasting my time :o)
as a old block told me years ago if you stop learning your dead.
I would hang on a bit to the new boards that addafruit are making for Arduino and sparkfun are making there new boards that are meant to use arduino library and are a lot faster
-
Keep your eyes open for an Arduino TRE when they come out, these are a joint board being developed by arduino and beaglebone.
DazTheGas
-
yah! I've been watching....dude, this can be soooo awesome!
I love that comment Dan! ...stop learning and your dead. (period. no emotion. it's just fact.)
MIT has nothing on us! Little terds....okay, smart little terds but terds nuntheless. haha! I'm just havin fun!
-
Now, if we can just get Simpson36 back in here....we'all should do a collaborative project with Mach4. Whatcha y'all think? We poll for the requirement, select the right hardware (ensuring the technology and resources can meet the requirement and the design will be stable), and we just start a thread....c'mon it'd be fun! funk the money, where's the love? hehe
-
yes that would be a good idea bit as Simpson said no need to reinvent the wheel as in arduino modbus that just need`s updated to the new version of arduino unless someone has already done it
-
Now, if we can just get Simpson36 back in here....we'all should do a collaborative project with Mach4.
You guys have passion and are excited about creating products for MACH4. New blood and new ideas being posted is exactly what this forum needs. I do not have time to do development threads at this time, but here I will post a bit about my projects in hopes that it will inspire and encourage any of the new members to strike out either on their own or in collaboration.
Any of you can send me a PM with info on a new thread and I will participate as my schedule allows . . which is not very much. Please do not send me questions via e-mail. Post here and I will answer if I can.
Here is some info on my current projects. I will provide more information on the Arduino question and Modbus question in a separate follow-on post.
I have two projects that involve the Arduino; Porting my 4th axis motor controller to MACH4 is completed. This is the controller: www.theInTurn.com (http://www.theInTurn.com) The ported version looks the same . . just TCP instead of USB . . and there are several added features.
Edit: Oops! I forgot to mention a new processor. Moving from the Arduino Mega to the Arduino DUE
The second project is adding 'super pendant' capabilities to the controller. That project is nearly complete. I am currently assembling the first prototype by neatly ( as much as is possible) combining this rat's nest:
(http://www.thecubestudio.com/InTurnRemoteCommandPendant/RatsNest01WEBsmall.jpg)
and the rest of the components into this new panel [1st proto . . will probably change], which fits the existing controller box (for upgradability):
(http://www.thecubestudio.com/InTurnRemoteCommandPendant/RCPpanelProto1LCDonBoxWEBsmall.jpg)
So there you go. Now get your own threads going with your projects!
-
Arduino IDE and Modbus info;
It may 'appear' as though all of the Arduino boards will run the same code, but that is largely due to a trick used by the Arduino IDE. It is a good trick and serves a good purpose for the intended audience, but it causes a lot of confusion when using third party libraries (like Modbus).
The IDE contains a file which has the required parameters for each Arduino board. You tell the IDE which board you are using. The IDE looks up the parameters for your board for use in compiling your 'sketches' [Arduino speak for 'programs').
This process is transparent to the user, so there is a common misconception that all Arduinos can run the same code, but that is far from correct. Code that compiles for earlier boards will not necessarily compile for the newer boards if Arduino has not yet updated the libraries or provided new ones. When you download and install the latest IDE, you also get the updated libraries, but there is a catch . . . . only the Arduino supplied libraries are updated.
This may have changed, but last I knew, there is no Arduino supplied Modbus library. There are quite a few public (licensed, but free) libraries floating around, but most are quite old and will not work with the newer board. Some have been updated here and there and I *think* there may be bone that has been updated as far as the Arduino MEGA. I started with these little development boards right before the latest MEGA came out and when it hit the shelves, there were NO Modbus libraries that worked with it . . and I did a LOT of searching.
Ultimately, I took one of the libraries that 'sort of ' worked and re-wrote the parts that needed to be changed for the MEGA's processor and to include and call the MEGA's libraries.
Next up came the DUE board which is a massive improvement over the MEGA, however, extensive searching did not turn up a working Modbus SLAVE for the DUE.
It was Modbus purgatory all over again, this time requiring a much more extensive rewrite of the code I was using on the MEGA.
Another unexpected challenge is that the DUE has no EEPROM . . . as in NONE, and the new board was 3.3v only. Fortunately, the Arduino Ethernet 'shield' (Arduino speak for 'daughter card') not only was compatible with the 3.3v DUE, but had an SD card reader to store stuff . . . except that the SD library did not work on the DUE . . catch 22. Eventually, that got worked out and the new DUE is buzzing along nicely.
The bottom line is that if you have to use a non-Arduino library, do not expect it to work transparently on any Arduino board. 'Private' libraries are likely to be board specific and even support library specific. The better news is that sometimes all you need to do is change the names of the include files to match the ones for your board.
Users will need to research the particular board they plan to use. That's why I stated in a previous post the choice of board, if you are not able to re-program or create your own libraries, should be determined, in large part, but whether a working library is available for it that you will need for your application.
Keep all of this in mind before rushing out to get the latest and greatest ne board. I believe the newest board is based on the DUE. Similar to the relationship between the Leanardo and Yun
-
I re wrote modbus from version 1 of arduino to 1.2 found a change log but past that I could not find any change log that was detailed enough to go to any other version of arduino a lot of the way call are done have changed so it could be one word that stuff it all up it`s quite simple to do but takes a long time I am lade up at the moment so I might play this week to see if I can port it over to the new version on a uno
-
Here`s Modbus redone to run on the new version of Arduino it`s for arduino uno only
-
sweet project!
Have you guys heard of MQTT? "MQTT is a light-weight publish/subscribe messaging protocol, there are already MQTT C and Java libraries with Lua". Basically we would use telemetry sensing to conduct an I/O action. For example, the table is done moving -> auto contact the operator / alarm / etc / -> turn output 30 on (do something in Mach 4) ---or being able to actuate the mill with mach4 over the internet no matter where you are at --- or with passive RFID, we can authorize certain people to use the mill only...etc.
sensor + audrino = client
MQTT server = broker + logic (described as a 'topic')
Mach 4 = subscriber
1. we create a 'topic' on the MQTT server
so...by using sensors on the mill, attached to the audrino (with relays or whatever applicable shields) using (wifi+PSU or power over Ethernet) will 'publish' a message to the corresponding 'topic'
2. the 'topic' is updated
3. Mach4 PLC has 'subscribed' to this topic and constantly looks to see for an update status, once the 'topic' is updated Mach 4 = do some user defined action
Have a looksy....http://www.eclipse.org/paho/ (http://www.eclipse.org/paho/)
Got the idea from...http://superhouse.tv/ (http://superhouse.tv/)
-
have fun
-
why not...attach a camera to a mircrocontroller and broadcast live to a server for you to watch anywhere...live streaming and control over the machine, if you are an authorized user :o) idk, probably been done before...
or maybe for live education mach4 purposes?
-
...remote access to user's computer with live streaming action of mill....to write custom scripts for their specific requirement....
-
its do able.
it may be done with the novakon atc`s if the owner of the mill wont's to have a camera I think it`s being considered as there is going to be a web interface for the atc`s so the maker of them can check all setting`s are correct and what if any problem`s come up.
it will more than likely be ported over to M4 as well
-
that modbus I ported over its for any board with the same chip set as a uno and mega. I will work on getting it done for 32u4 boards I just have to find the different words used between ATmega 328 and 32u4 boards once I have it done I will test on a uno in M4 only
-
I have to look into this Modbus y'all keep talking about....it seems as if it is a must have, as if you have an external hardware requirement but no more physical I/O pins. Whereas, Modbus is the software interface (plugin) via Ethernet/TCP's between your hardware and Mach allowing for a lot of I/O signals.
-
yep ever a Arduino or a PLC
-
Well ive had lots of work lately and not much time for coding (till now).
Ive decided i am sticking with the arduino yun cause from it i can use python, linux and of course the arduinos own offering. got a bit of progress with it talking to mach4 over tcp so i will continue on this line.
DazTheGas
-
did you find the info of how to make modbus work with the 32u4 boards
-
Its not 100% yet but im using the YunClient and Bridge libraries across to the Linux OS (openwrt) which i installed a python library called pymodbus. :).
As i said though, not 100% reliable at moment.
DazTheGas
-
your doing that way I don't like linux have fun
-
aww, c'mon Daniel. You just need to look at it like Linux as another avenue of approach. Python is actually similar to Lua....and Python has an extensive library that is available to us. I would venture to say....your's, Simpson's, and Daz's approach is another opportunity for all of us on this forum :o)
-
I am dyslexic so it`s not that easy I can read code and under stand it but getting it down takes time.
I have been down the Linux and Linux cnc road just did not like how it works
-
I hear ya. I'm all in this by myself. It would be so much better if there was someone else close by. Well, I'm moving to Rock Island Arsenal in two weeks...wonder who I will find there? Maybe I'll just walk in and ask if they machined an M65 Atomic Cannon lately. :)
-
I just googled Rock Island they will be some cool toys there
-
Its not 100% yet but im using the YunClient and Bridge libraries across to the Linux OS (openwrt) which i installed a python library called pymodbus. :).
As i said though, not 100% reliable at moment.
DazTheGas
I think this is a good track to be on and I very nearly started down this road myself, except with the new Rasberry. So far it has not been necessary to open the box on that project because at the moment I am looking at off-loading a lot of the processing from the Arduino DUE to MACH4 and also the GPU on the touch screen itself.
Based on my experience with a few of the Atmel processors, I thing the Yun is not up to the task or running Modbus on top of Linux and doing anything else useful at the same time, but if you can get something working and it turns out to overwhelm the Yun, you have a ready path to far more powerful processors, so you may not need to rewind very much to port everything over.
I am up to the point of doing field testing on my own TCP Modbus products on actual machines. First my own and then to my group of testers. To that end, I have installed MACH 3 and MACH4 with and ESS on a test mill and in that process I discovered an interesting anomaly with MACH3.
While MACH4 consumes between 4% and 8% of CPU power to run TCP Modbus, MACH3 is hovering between 45% and 54% . . . doing nothing except running TCP Modbus. Screen DRO response is very choppy and jogging is jerky somewhat unpredictable. Turn off TCP Modbus and MACH3 returns to smooth operation. I am going to spend some time to see if this is fixable, but if not, then TCP Modbus will prove impractical for MACH3.
-
I would not bother with M3 to much have you ever had a look at the PoKeys57CNC I am going to be changing over to one soon for other things just out of interest, I have not seen any new youtube vids from you lately
-
I would not bother with M3 to much have you ever had a look at the PoKeys57CNC I am going to be changing over to one soon for other things just out of interest, I have not seen any new youtube vids from you lately
Looks interesting. For testing, I am going to go thru the available TCP motion controllers that are popular with MACH4. I already have the ESS up and running for testing and for my own equipment, I will be using a CSMCIO motion controller http://www.cs-lab.eu/en/produkt-2,2-CSMIOIPS___6_axis_Ethernet_Motion_Controller_STEPDIR_with_connectors.html (http://www.cs-lab.eu/en/produkt-2,2-CSMIOIPS___6_axis_Ethernet_Motion_Controller_STEPDIR_with_connectors.html) based primarily on my great respect for the advice of Hood, a major contributor here.
I am interested in the Pokeys 56E http://www.poscope.com/PoKeys56E (http://www.poscope.com/PoKeys56E) to use as a TCP Modbus 'portal' to relieve that processing from the DUE. I have the older USB version that was acquired for some past project, but I have never used it.
As far as videos, I can only post stuff of my own. Most projects are done under NDA and I would be in big trouble is I posted videos of them . . LOL!
However, there are two, possible three, new videos series coming up. The IH mill conversion that ran over many videos will be coming back into the shop for conversion to MACH4 using the above mentioned motion controller and the setup will be getting one of the first combination InTurn™ 4th axis motor controller /Mach4 pendants as well as improved ATC software. Most of these Off-Shore mills have very flexible tables, so reinforcing the table *might* also be done . . that is undecided at this point.
I am also going to FINALLY start the 'big mill' project. That involved building an all new Bridgeport sized mill specifically to be a stable platform for the new InTurn™ ULTRA. It will have truly massive ball slides and ball screws.
The third 'possible' video series would cover the development of the MACH4 pendant . . . but I am reluctant to do that one because of the proprietary nature of it . . and the fact that I have not been collecting any video footage . . which makes it difficult to put one togather ;).
-
In addition to using co-processors like the single chip Ethernet and possibly a Pokeys board to run the TCP Modbus (both mentioned earlier), I wanted to include a practical example of off-loading processing from the Arduino to MACH4 as also mentioned in an earlier post.
The CPU in your computer is many times more powerful than any of the little development boards. The version of LUA that is embedded in MACH4 is all Floating Point (not a good thing), but it is also extremely fast and according to statements by the MACH4 team, can run in its own thread (as was done for the PLC).
Here is the example:
The actual test case is collecting data from a pair of quadrature encoders on a Joystick and sending the data to MACH4 for use in performing jogging. The data needs considerable processing to determine basic stuff like stick position, but also more complex calculation to determine the speed at which the stick is being moved (including detecting zero stick movement) and calculating an exponential ramp based on the combined coordinate distance from center, while remaining biased toward the greater deflected axis.
This processing was being done by the DUE prior to sending the final jog speed, axis and direction data over Modbus for MACH4 to use in moving the mill table. Averaging several available benchmarks, the DUE works out to be about 7.5x faster than the MEGA at munching on FP calculations. But a 3.2ghx Intel CPU is faster . . . . . a LOT faster.
The processing described above has been moved to LUA and the DUE now simply collects and sends the raw data. While I did not do formal speed tests, I would estimate based on the frequency of updating the DRO with new numbers, that the speed has nearly doubled. So a 2x improvement in responsiveness over Arduino's fastest board is attainable in MACH4 at zero cost.
Food for thought.