I am a complete layman and need my hand held on MODBUS communication to a Fuji VFD

[Majourlittle]

First, howdy everyone! I'm Justin from Oklahoma and have a project that I am working on that is eating my lunch. I have done PLC programs in the past that were basic button and run command stuff with basic inputs and outputs.  This project is a little more in depth and it is way beyond my comprehension. I need to communicate with a Fuji VFD drive and write a number of things to it, but this is my first modbus project, and in fact it is my first "communication" program, which is to say that have to be talked to like a child to comprehend. 

My goal right now is to make a simple program that commands the drive to run, reverse and stop. I have as secondary to command the VFD speed, but right now the drive is set up to control that manually. Once I understand how this works, I am confident I can move to all of the other read/write stuff I need to know.

As it stands, I am flat out not getting anything to work and I am trying to eliminate variables. The code for this program is attached. it is based off of the Read/Write example of MODBUS comm on youtube by Unitronics.

I am using a V570 and a Fuji Mini.  I am connected to port 1 and to the VFD using an RJ-45 cord. The switches on the back of the PLC are set to RJ-485 terminate. The VFD has been set to terminate as well as they are connected directly. 

The VFD is set up in the following manner

H30 = 2 (this is local Hz command, remote run command)

Y01 = 1 (slave 1)

Y04 = 3  (19,200)

Y06 = 0  (no parity)

Y07 = 0 (2 bit stop)

y10 = (MODBUS RTU)

I have the communication set up as noted below. I have all of the initialize setpoint to match that of the VFD controller. 

 

I think that the issue lies in the formatting of my commands. I have looked at some other examples of other PLCs running the Fuji drive and there is a lot of conversion from Hex to Decimal. I personally don't know if I am converting these correctly, or if there needs to be more to the string. I have tried a few different things in changing the slave operand and the value to preset, but mostly were shots in the dark. Looking at the preset single register, the format is defined below.  for running forward, we would use the S06 Function Command which would be 0706 in hex, or 1798 in decimal.

 

At this point is where I flat out fall on my face. I simply cannot grasp what is expected of me. I am not sure what I am expected to write, or convert the data. It appears that I am suppose to send "XF" and "XR" to the drive, but I cannot grasp what I am suppose to do with this information.  I cannot tie the matrix of commands into the proper format in my head, and determine where this data needs to be placed in the ladder logic block.

 

Can anyone beat this idiot with a MODBUS stick until I get it? I would really appreciate any insight you can give.

RS-485_Users_Manual_24A7-E-0082.pdf VFD Command Practice.vlp

[Majourlittle]

This must be a much harder question than I thought. I have talked to the panel supplier with no luck.

 

At this point I am ready to pay someone to finish this.  I am either just too inexperienced to understand or just too dumb to speak hex conversions.  Any takers? 

[Joe Tauser]

Hi Justin -

If it makes you feel any better, that manual is as clear as mud.  It spends way too much time discussing how to set up a Modbus frame, which the PLC will handle for you.  The examples on page 3-11 are horrible and ill-explained.

First off, all devices on a Modbus network must have different addresses.  In network 4 you set the PLC to 1, but you've also set the slave to 1.  This won't work; set the drive to slave ID 2.

If you're not using port 2 on the V570 then use that for Modbus communication.  Leave port 1 open for programming.   A little known fact about Unitronics Vision series is if you've connected to the V570 via USB then serial port 1 is disabled and USB communication takes over that port.

My experience has been Unitronics Modbus works much better using 8 data bits, even parity, and 1 stop bit.  Change your drive to match this. 

It looks like you are going to have to play in Hex Land.   Handy tip - if you're putting a constant in you can click the little drop-down box when you enter the number and select "HEX".  It will convert it for you:

 

The stupid manual puts the function codes on page 3-4 and you're kind of on your own to get the data needed to implement the function.

To replicate the digital input terminals on the drive, you have to combine this 

with this on page 3-7

To answer your question, XF is in the +5 column of the coil number 9 row, so the proper value for the bit is 14 but then you have to subtract 1 because the bits start counting at 0.  So that would be 13 or D hex.  For FWD it would be 1.

What is the difference between XF and FWD?

From what I can tell, you need to follow the function with the proper data.  So to set XF you would use 0706 data 000E; to set FWD you would send 0706 data 000F.

 

Without the hardware in front of me I can't test any of this.  Your first challenge is to make sure the RS485 wiring is correct regarding the D+ and D- connection.

 

Let us know if any of this works or your further thoughts.

Joe T.

 

 

PS - Or you could get rid of this drive and get one that's easier to control.  I personally prefer Invertek.

 

 

 

VFD Command Practice JT.vlp

[Ausman]

I agree with Joe, an over-the-top manual that is written by people paid by the word, who don't believe in conveying simple basics. 🙂  He's deciphered things well enough and worked on it for you.

In case you haven't thought of it, I have run this sort of drive without using 485.  I've quickly checked and it looks like you could run it at a number of fixed speeds (set by you) using it's digital inputs, or could run it using analogue input.  Depending on what is needed, direct input is often the easiest to implement.  You get around all aspects of using 485, which just complicates a process.

I always try to use the KISS principle, but sometimes in the real world that is not possible.  Things must be complex  these days.  So many cases of Technology for Technology's sake.  Take for instance listening to your car radio.  Instead of receiving a signal from a radio station transmitter that is received and played by a radio in your car, you now use your mobile to use your mobile network access to hook into the live stream that the radio station does, then your mobile decodes it and uses bluetooth etc to link to your car audio system that then delivers it exactly the same way it used to be done.....to your ears through the speakers.  That's Sooooo much simpler, isn't it?  !#@!!#  And of course it is soooo muchhhh better for "saving the planet" as well, with all those extra steps and equipment needed.  But don't get me going on that one....  😖

cheers, Aus

[John_R]

On 11/23/2024 at 12:26 AM, Joe Tauser said:

PS - Or you could get rid of this drive and get one that's easier to control.  I personally prefer Invertek.

I've never had the pleasure of working with FUJI VFD's..😵

I've had good luck in the past using Modbus to control Allen Bradley PowerFlex VFD's.

One project I did had 6 AB drives, all controlled via Modbus, with (Joe's favorite) State Machine logic parsing the commands to each without missing a beat..

It can be done..😋

JohnR

[Majourlittle]

@Joe Tauser you were spot on with some of my issue with the comm1 and whatnot. I had a ticket in with unitronics and they pointed out the same issues.  Another issue I had was that the cable I was using was an RJ12 to RJ45 cable and I realized after walking through the entire setup once more that the cable was not wired correctly. I tried to decipher the wiring schematics and clipped in a new RJ45 plug.  Still no luck.... Swapped wires.... Same.

Struggled and struggled until I went to my panel that is installed on my machine to find out that PLC and drive are connected through port 3 using an ethernet cable. I think that was when I called it quits. Tired of loosing sleep over this.

Decided to follow @Ausman response and had luck with running the VFD with digital outputs for the forward and reverse and an analog output to drive frequency.  I wanted the Modbus communication as I wanted to command ramp speed and a few other things, but at this point, ill just review the timers and step functions to simulate ramp speed.

Thanks for everyone that looked into this! I have had many a question answered through this forum already and look forward to wrapping this thing up in a week. I am sure that ill have more questions as I start to clean this up. 

[Joe Tauser]

3 hours ago, Majourlittle said:

Decided to follow @Ausman response and had luck with running the VFD with digital outputs for the forward and reverse and an analog output to drive frequency. 

That is my standard design.  I only control drives via communication when the customer requests/demands it.

When you control a drive via communication, you lock yourself and anyone down the road who has to work on the machine into that manufacturer and that model.  Good luck if they don't make it anymore or have a long lead time.

Don't over-complicate the controls if you don't need to.

 

Joe T.

[Ausman]

4 hours ago, Majourlittle said:

I wanted to command ramp speed and a few other things

I would guess that you can still do this via modbus.  Just keep the actual "running" commands the same as you have done via direct, and if you need to alter ramps and other parameters to suit a particular need you could then send them down the 485.  If it relates to starting a particular load, then do it first, check for the correct result via a readback, and then get things underway.  Of course this can all relate to how quickly your system needs to respond to it's work. 

The other way is to simply adjust your ramps in the plc itself.  It is not hard to set up varying ramps for linearisations running analogue outputs.  Again it relates to the system's needs, but you set up self-resetting counters that run from the 1.25s Interrupt Routine that do an Increment or Decrement from your Ramp Speed calculator logic that is part of the linearisation you use for the analogue output.    The 1.25s Interrupt is a useful thing, but often missed.  In the help index look up Interrupt, choose Interrupt Routines from the results and then scroll down a bit in what opens. (Note that if your scan rate is fairly stable and quick enough you can simply use each scan as the counter trip.)  To vary the ramp speed you vary the reset number. Ramping is done by always having a "target" amount that is then compared to where it currently is, the desired speed of change that sets the 1.25s reset number, and increment/decrement adjusts the current amount until it reaches the target.  Target is NOT the actual output. I know this explanation is pretty much Marvin-type-talk, but I hope you got it!   For an example of interrupt usage, see this and perhaps read the entire topic.

https://forum.unitronics.com/topic/4599-totalizer-to-gpm/#findComment-17077

cheers, Aus

[Majourlittle]

The interrupt seems like the perfect tool From the example, I couldn't confirm if I could call it only when a certain event is happening or if it was always being called. 

Something similar to this untested example

[Joe Tauser]

That's not how to use the interrupt.  Open the Help and search for "interrupt" and look it over.

Once you define the interrupt subroutine, it always runs. 

You don't have to call it from the Main.  Just enter code as you normally would, but don't put too much in there as you don't want the solve time of the elements (typically a couple of microseconds) to overrun the interrupt time. 

You've been good about posting your .vlp file with questions.  That helps us immensely, as we can open the file and look at things that affect the question but you didn't know about.

Joe T.

[Majourlittle]

This is not complete and partially tested.  The intent is to spin up a brake rotor, then add hydraulic pressure to it and then cycle the rotor speed a few times. What is not written yet is the removal of the hydraulic pressure and bringing the rotor back to zero.

If the interrupt is executed on every pass, thenBurnishing System.vlp maybe it needs a contact added to the front of the logic to indicate that it is required during this pass?

[Joe Tauser]

Yes.

 

[Majourlittle]

Just for good measure, this is the same with the contact added. 

 

Burnishing System.vlp

[Majourlittle]

I see a flaw in this step adjustment that I proposed. The issue is that the step value is not a whole integer but ends up as a decimal.  I fear that I need to reconsider this and just do the step up and down as a timer delay and control the ramp speed with the VFD.  In addition to creating a fractional increment, I am variable-defining the distance the ramp up and down needs to be. 

More thinking is to be done.

[Flex727]

I haven't been following this thread carefully, so it may not be applicable in this situation, but be sure you understand and have considered the concept of implied decimal.

[Majourlittle]

I think I understand the concept (still drooling on myself) in that I can represent 100.00 as 10,000 and sort it out later, I think that I have added too much to the variable that I am not incrementing by a whole number however I cut it.  I think that I need to kill/control some variable to allow for some level of adjustment without fully hardcoding the ramp up and down. 

[Ausman]

I haven't looked at anything since my last posts, but if you're talking decimal issues, you're not working completely like I suggested.  Perhaps you haven't thought/realised that you can do linearisations on the control figures  running in a linearisation.  I often have cascading linearisations to arrive at the optimum final result for a given situation.

cheers, Aus

[Majourlittle]

Ok, I have this program working as well as I can think. I still lack a few "features" but for now I need to fix this issue I have below. 

using the Interrupt 2.5ms, I have created a routine where the main program bring the VFD up to speed and when the interrupt is called, it should cycle the speed down to half speed and then back up. This would create a cycle and once it has reached the correct number of cycles, it would continue on with the rest of the program.

The issue is that the first round of the cycles, it counts but it does not decrease the VFD command speed. In this case, it deceases by 1 and then holds as it goes through the rest of the count, then increases by two on the back end. Once the cycle is over, then it functions perfectly as intended on the remaining cycle counts.

I am sure that this is an easy one, but I am stumped.  

 

@ausman, I did increase the input value considerably (from 100 to 10,000) so that I could create the steps required. It may not be how you intended, but it is working well enough. 

Code is attached and video of the watch.

Burnishing System.vlp

[Ausman]

I've only looked at the video and I think that I need to do a detailed explain of my concepts.  I can't do this at present due to other commitments, allow perhaps 2 days.

cheers, Aus

[Majourlittle]

I figured out the issue I was having as it was logic related, but I am still very very interested in a breakdown from you on this interrupt concept. I know you have a better understanding of what is going on and i would love to learn some more.

 

BTW, current program attached. Burnishing System.vlp