Wondering if anyone in the community would be excited to see a driver that uses the FANUC FOCAS library to collect data from a FANUC controlled CNC machine?
My understanding is that FANUC has provided a C++ library, fwlib32.dll, that can be used to build a software application that can collect data from the control. FANUC has their own software that presumably uses this library and there are 3rd party applications that again, I’m assuming, use this library under the hood to present the data through open protocols like OPC or MTConnect.
Unless I’m missing something, it seems like it would be really nice to have this capability wrapped into a driver for Ignition. Anyone know if something like this already exists? Or a developer willing to take a crack at it?
For the time being, looks like we have to add another layer. If anyone sees it differently, please share.
I’m very green still on the module development front, but based on what I’ve seen and know, I think we need to break outside of Ignition to write some middleware to use those libraries or wait for FANUC to release Java or python libraries to even consider modules or libraries for this in Ignition.
I think the most direct route I know of now is using Kepware and their driver as a 3rd party OPC server.
Yes, when I mentioned OPC, Kepware is what I had in mind. I figured if they can do it, would be nice to bring that capability to Ignition and drop the a dependency. I just don’t have the experience yet to know that it “works flawlessly” but at least that’s encouraging.
I wouldn’t hold your breath for this one. We’re opening up a little to using native libraries, but we don’t usually develop Windows-only solutions (OPC Classic being a notable exception), and on top of that, it seems to require that both the FOCAS library and some other FANUC unsolicited messaging server, available “from your distributor”, already be installed on the PC to function.
More digging: it looks like inventcom, who appear to be the developers of fwlib32, relationship to FANUC unclear to me, also have software called CNCnetPDM and it includes an OPC UA server with connectivity for all these devices: OPC UA Server | CNCnetPDM Manual | Support | inventcom
The one issue I had with the Kepware driver, was the updates lagged sometimes. It turns out that each channel can be configured with something like 255 devices, but the manual suggests one channel per device. Once I did that, the responsiveness was so much better.
I very rarely ever have to mess with it. 99% of the time it is just when I need to add another machine.
If FANUC ever publishes their on-the-wire packet formats, I’d tackle this. No way would I bother with a Windows-only DLL. If Windows has to be in the picture, I’d just use Kepware.
I'm trying to use Kepware with Fanuc Focas driver, however I learned that it requires Focas DLL files to run. Did you have to copy DLL files on the Kepware host as well?
OP here. Yes you need to provide the FOCAS dll to Kepware, they are not provided with the Kepware installation, presumably due to a licensing issue. I believe we purchased the libraries from FANUC. I don’t recall specific licensing terms. They mailed me a CD. I had to ask for a download link. . This experience is largely why I made this post in the first place.
Any news on this front? We are attempting to support a Tsugami machine with FANUC FOCAS, and I was initially told it was "just like MTConnect" but that is obviously not the case.
Just to clarify for future readers of this thread. I am always skeptical of how things work until I see the setup it actually takes to make the "sales demo" work. FANUC FOCAS is one of a few examples that have taught me to be this way.
I've heard people claim that FANUC is "very open", all "inputs and outputs" etc. I wholly disagree. The format of data on the wire is proprietary. FANUC provides fwlib.dll so "anyone" can develop software that will be able to understand that proprietary format, but that's not what anyone would expect when they hear "open".
Clearly it's unreasonable to think that every manufacturer that wants to integrate to FANUC CNCs will write their own adapter (protocol converter); the model is designed to sell 3rd party commercial software. Now, I don't necessarily have a problem with any of that but letting manufacturers (end users) believe FANUC FOCAS is all you need is misleading. You need software to make the FOCAS calls and "adapt" (stealing the MTConnect concept) to something truly open. The only realistic option is 3rd party software.
MTConnect is completely different in that is built upon open standards. The agent will handle web requests and can even be configured to publish to an MQTT broker. Not to sound like an MTC fanboy; I think it's important to illustrate the difference between software that's truly open vs something that requires a proprietary library.
Looks like someone partially reversed the protocol at one point:
It's kind of abandoned (although a few recent forks exist, there's not a lot of activity on them either), maybe someone out there with lots of time on their hands can pick it up?
Not a comment on the quality of this driver, but it just has a bunch of the fanuc DLLs checked into source control. It's not a reverse engineered implementation of anything.
. This experience is largely why I made this post in the first place.