LukeDuke4084 (Customer) asked a question.
I am trying to control a VFD with a click PLC. I am using a C0-01DR-D PLC and am trying to control a Proflex PR6100 series VFD using RS-485. This is a bench test for knowledge and practice and is my first attempt at MODBUS comms. I have managed to set up receive commands where the VFD will report output frequency and output amperage for me. But there is clearly something I am missing as I cannot control the VFD. I can't figure out how to start and stop it over 485, nor can I control set frequency. I can use wires and Y001 as an output to control the VFD start/stop signal, but I was under the impression that I could do all of it over the 485 comms. I have found the address to send frequency and run commands to, but I don't know if it needs the data in a certain format or what? Any advice would be appreciated. Any other information I can provide to help clarify I'll be happy to post up. Thanks.
If you post your code, this can be easily diagnosed. For one, how are your controlling the Sends and Receives? Click does not automatically control them, so you may be attempting to do them simultaneously.
I have two subroutines, one to monitor data and one to send commands. I noticed that if I sent requests at the same time it didn't work. So, I used rising edge contacts to separate them. See attached screenshots. Any advice is much appreciated. Currently, I am just trying to write command frequency, the PLC is lighting the send and success bits like it is working properly, but the VFD is not changing speed.
Quick sanity check: are you calling the subroutines from the main program? If so, how often. The Send you have in the picture is enabled all the time so if the sub is also being called every scan then you may be trying to talk too quickly.
Hi LukeDuke4084,
You have to set the timing between each of the commands.
Since you are sending several send instructions in our program then use the output bits to trigger the next instruction, etc.
https://accautomation.ca/click-plc-advancedhmi-communication/
I hope this helps you out.
Regards,
Garry
https://accautomation.ca/series/click-plc/
Also, if you are also using a GS series VFD from AD there is a chapter in the manual specifically for CLICK comms that may be helpful. And really, as far as structure for the code, it may be helpful anyway regardless of the type of VFD. Check out Chapter 5: https://cdn.automationdirect.com/static/manuals/gs3m/gs3m.html
Thanks for all the advice.
mashva, below is a screenshot of my main program. It just calls each of the subroutines. Unfortunately, I am pretty green in programming and so I don't understand how all the timing works. I am going to implement what Garry recommended and chain my comms so that they are orderly. I will also check out the link you posted and see if that helps me some. I will let you guys know how things go.
That will work once you get the sequencing of the various comms as Gary suggested. Its easy to forget that "Call" step especially if you are used to having every sub/task run each scan by default.
Just think of a schenario where you're talking at the same time as someone is talking to you. This is what the Click experiences when timing between commands are not performed.
screenshot
I would avoid this in the first place. As a learning exercise this is fine but as a practice, it's a very bad one.
On the one hand, PLC's tend to stick around "forever" (20+ years). If you buy a relatively new PLC today, you can probably still buy parts 20 years from now. On the other hand VFD's get obsoleted/outdated about every 5-10 years by the manufacturers, and they have built in "life" so that about 10-15 years out they have to be replaced. By that time though spares are no longer available. Just like PC's, you are constantly on the "upgrade treadmill". In the PC world they have overcome this somewhat using "profiles", HAL's (hardware abstraction language), and mostly standardizing on PC instruction sets and operating system standards like POSIX. There is a standardized set of parameters for a USB "mouse" for instance. Mice are all but interchangeable to the point where I can plug one into say an Android tablet and it "just works" without changing code (device drivers). I can load almost any software even for different operating system versions (within reason) and I can run down to the discount store if my mouse dies and just buy one and it works.
However Modbus.org does not have device profiles. The menu structures and a lot of basic design decisions about how the control and data paths within the VFD software, even though the are all very similar in how they work, are extremely different from one manufacturer or even one drive series to another. There is zero interchangeability among VFD's, even within the same manufacturer. Sometimes even bumping up in ratings throws you into a totally different VFD from the same manufacturer. Unlike VFD's, programmers and engineers are theoretically interchangeable so 10 years down the road when you aren't there, someone is going to be dealing with your legacy PLC program and a failed VFD, and no easy way to fix either one.
Device profiles have started to come around. But they keep getting killed. Two examples come to mind. ISA has implemented them for HART. But they made it so hard and so complicated and outright bureacratic that few devices actually support it and it makes the device programmers very, very expensive and requires high monthly or annual fees to maintain libraries of data needed to make it work....hence not practical for anyone but billion dollar chemical plants. Over in the ODVA camp they have a nice set of device profiles. So the biggest name in ODVA, Rockwell, only implements proprietary mostly undocumented device profiles, thank you very much. So although the concept exists, so far nobody in the controls business has actually bothered to implement this except sporadically. Schneider's "process drives" do actually implement the ODVA Ethernet/IP device profiles for drives though so I'll have to toss them an attaboy for doing it on their latest VFD's.
If you just accept the fact though that device profiles are just not a "thing" outside of the PC world, then what? Use analog and discrete control then this won't happen and things can be repaired/replaced when they fail even if a totally different brand and model has to be used. It would be far better if everything could be done with 2 wire Modbus or 4/8 wire Ethernet, and that drives are completely interchangeable. But that's not the world we live in. The drive control hardware/software is being driven by the PC market and has been for the last 30+ years. The power transistors themselves seem to go some sort of dramatic technological revolution about every 10 years that totally obsoletes the previous generation, unlike say SCR's and soft starts that are almost unchanged since the 1970's. Every time I feel like this is probably going to start slowing down though, something new comes along. The latest thing is SiC and GaN chips. Although these are not as dramatic as say HVIGBT or IGBT's, to say nothing of the impact of DSP chips that allowed vector drives to become common place and the same price as scalar drives, they are still causing nearly every VFD manufacturer to phase out their old existing VFD lines and to introduce new ones onto the market.
So here's to hoping that one day we can all just use Modbus or Ethernet/IP and that huge racks of IO will start to slowly slip away into obscurity, replaced by simple network connections. But until that happens, stick with old school. At least "new school" can still support it when the PLC gets upgraded.