Tim
Tormach 1100-3, Grizzly G0709 lathe, Clausing 8520 mill, SolidWorks, HSMWorks.
This needs to be compact, efficient code, with minimal graphics. The HTML generators I've tried all generate massive amounts of unnecessary code, and style sheets that are far bigger than the whole final code should be. I've got most of it done now anyway.
Regards,
Ray L.
Oh well, then you should try using the HTML output from MS Word...This needs to be compact, efficient code, with minimal graphics.
Cheers
Roger
(PS: for those who do not have my sense of humour ... NOT)
Over the last few days, in my very limited spare time, I got the web interface for the ATC nearly finished off. The HTML content is done, and the web server code is integrated into the ATC firmware and working perfectly. All that remains is to "plumb-up" the data inter-connections, so commands and parameter changes issued through the web interface actually execute and/or update the running firmware. That is a tedious, but very simple, task.
This has also forced me to implement the logical-to-physical mapping on tools, so you can put any tool in any open slot in the carousel, and the ATC will make the correct selection when the tool is called up by logical tool number. This makes me think I should provide a UI for loading tools either by carousel slot number, or by logical tool number. I'll have to give that some thought....
Regards,
Ray L.
Personally I think the logical-physical mapping for a small machine should be 1-1 using the KISS system.
You can certainly run it that way - just don't change the default settings. But NOT having mapping requires the CAM to re-number the tools, which means you MUST move the tools around in the ATC for each job, even if you already have all necessary tools in there, bu just in the wrong order. It's a simple feature, and need not be used it you don't want to.
Regards,
Ray L.
Tool mapping I can see and understand. What has me concerned is the window where you can adjust PID. That I think the customer shouldn't have anything to do with. It's leaving an open can of worms to the inexperienced tuner that will try to have it's tool change faster than originally designed. I think being that you can diagnose over internet remotely, you'll have to constantly train people how to properly tune the motors. It's OK if you do it, but the majority out there don't understand it.
Well than, well done. I would just hate it if it could be messed with by the end user.The user won't necessarily have access to that, or the Status page. But they still need to exist, if only for my use.
Imagine someone thinking to have a tool change as fast as a Robodrill or Brother. That would be unrealistic on their part, but I guarantee you, some would try it.
With TTS, their are limits as you've noted many times before.
The two CAM programs I've used to date allow me to specify tool numbers for every OP. As long as the ATC slots are numbered in an easily visible way then that would work for me.
I will say that I don't have TTC and need to measure tool height on every manual change (I have an NM200). If I were to have a Torus with the ATC AND more tool holders than ATC slots, then obviously I'd need to think about mapping, or else modify the tool table in the control each time.
I'd add that the only reason I'd consider selling the NM200 to replace it with a Torus is if the ATC were available, so keep on keeping on.
Great progress Ray.
I'm curious how the communication interface would work between mach and the ATC controller. Tool mapping sounds great to me. So I'm guessing when mach calls tool 92 for example, your interface would allow you to assign tool 92 to ATC physical location 2 ?. Just trying to wrap my head around the process from CAM setup to execution at the mill. My CAM system is away from the mill and I transfer files via the cloud. I was thinking I could have the post generate my mapping in comments at the file header for example: 92-2 (tool 92 = ATC position 2). When I'm at the mill I could then configure the ATC accordingly. Regarding the HTML web interface, will this be operated from the mill computer or is the ATC going to have its own display/keypad interface.
Thanks
Matt
Matt,
Your understanding is basically correct. You work entirely in logical tool numbers, 1-9999. When you start a job, you tell the toolchanger logical tool #5 is in physical "slot" 11 of the ATC. When the g-code calls for tool 5, the ATC will know to fetch it from slot 11 in the ATC. The mapping, in the simplest case, will be manually configured using the ATCs browser interface.
In many CAMs the POST is flexible enough to allow you to output a separate tool file, in addition to the g-code file. I've been doing that for years. Mach3 has a defined tool file format, so if the CAM writes a file in that format, Mach3 can load it automatically. When I get around to doing the ATC plug-in, I'd expect it could easily be made to transfer the Mach3 tool information to the ATC automatically. That would require "re-purposing" one of the little-used Mach3 tool fields (wear offset?) as the physical tool number. Worst case, I'll define a simple text-based tool file format, and the plug-in will have the ability to read and transfer that file to the ATC.
The ATC will have two logical connections to the PC, both over Ethernet. The first is a simple UDP connection, which is how Mach3 will communicate with the ATC. The second is the web interface, which will be accessible to any PC with network access to the subnet the ATC is on. This means, for example, if your machine is on a WiFi network, you'll be able to access and control the ATC through the browser on your smartphone or tablet.
Another option that will be loaded down the road, is the ability to send an e-mail if anything goes wrong. For example, an ATC fault.
Regards,
Ray L.
Awesome Ray,
as usual, you thought of everything.
Thanks
Email and 2 sub net is verry cool i like if ,..
Gesendet von iPad mit Tapatalk
Despite the frickin' FREEZING weather here the last 10 days, I braved my way out to the (unheated) shop today and tested out the functionality of the ATC web interface on the machine itself. All seems to work perfectly! Except for some minor rendering issues on the rather old Win7 version of IE on that machine, all looks and works as it should, and I was able to both test, and actually operate, the ATC through the browser with no issues. Unfortunately, an Ethernet hub, or crossover cable, is required to make the connection between the PC and the ATC. I guess the ATC kit will have to include either a small hub, or perhaps just its own Ethernet card, capable of performing the necessary crossover function internally, allowing the ATC to "play nice" with the ESS which is now standard on all Novakon machines.
I've also updated the web server code so I can now handle JPG, GIF and PNG image files. This will make it easy to "prettify" the web interface by using image buttons, and other window-dressing.
Regards,
Ray L.
Ray, A simple crossover cable would work. No need for a switch. Just swap the orange and green pair locations.
https://www.trangosys.com/cat-5-ethe...ut-assignments
Plenty of solutions. A switch. Another Ethernet card. Swapping the single port card for a dual port if possible in the machine. I would just document the options and let the end user make the decision.
It sticks in my mind that some ethernet interfaces these days are adaptive: they don't care which pair is which. Rather cute engineering to be able to handle 100 MHz through switches like that, but it does solve a few installation problems.crossover cable
Cheers
Roger
Anything running a gigabit capable chipset is capable of auto-negotiation as well as auto detection. Older 100 meg and 10 meg interface can't determine if they should be MDI or MDI-X on their own. In those instances you need a crossover cable if you are connecting end point devices directly to each other with no intermediary such as a hub or switch.