hi All
Any chance somebody explains me why real numbers are not used in VFD drives speed reference etc?
So instead of sending sending 90.9 percentage of speed i would have to multiple it by 10 and send 909 which is then converted by the drive itself?
Why floating point arithmetic in not used in drives?

Regards

 

From my experience with many communication formats, it's less about what numbers the VFD could use to perform arithmetic, but more about how it interacts with the other devices on the network. Most controllers are based on registers of either 16 or 32 bits, which directly translate to integers or double integers. 16 bits, the standard integer or word, has been the normal data packet size for a long time, although there are modern networks that can handle 32 bits directly. Like Ethernet - there are many devices that use Ethernet and directly pass Real values back and forth. But they can't do that on a 16-bit based network without a lot more effort to split and combine two registers.

Real values take up 32 bits, so sending those over a network, say Modbus TCP, would take two register values, then they must be recombined at the VFD into one Real value, then the arithmetic performed. Not only is that extra time, but it also requires making a different process for every possible network connection. Instead, they use standard integers (not just VFDs by the way, this is true for a great many network devices), and those integers translate to either bit codes or equivalent decimal values at the end. If decimal precision is required, scaling is a super easy way to get more precision from a normal integer.

 

The anticipated range of value for something like speed % is a relatively small number in binary. If that were put into a float (32 bit) there would be a whole lot of binary space never used. Speed expected would range 0-100 (maybe with some overspeed +100 by some amount). In binary the top of the range (100) would be 1100100 with no exponent. If I want to add one decimal place and have 100.0 purely as an integer (1000) that's still only 1111101000 decimal. Why put a value with a small expected range into a big 32 bit data packet that goes largely unused?

Now if you want to talk some larger value you may want to consider floats. Run hours. I want to convey run hours but I put it into a 16 bit integer and have the end user apply one point of decimal precision 65535 (all ones in binary) as an integer turns into 6553.5 run hours. That's 273 days which is pretty easy to reach for industrial equipment. Do I want the run hours counter turning back over to 0 every 273 days, no. There are ways to handle big numbers using two 16 bit words (most significant word/ least significant word) , or maybe put big numbers into floats or long floats.

To me putting a small number in a big packet is sloppy. I've also seen some things programmed as signed values where the expected range can never be below zero, sloppy. It appears that someone is programming as efficiently as possible.

 

Another point to consider is from a design perspective of the VFD. There is a performance hit when using floating point numbers, and the associated floating point arithmetic, compared to integer numbers and arithmetic. And, as was already explained, while floating point allows you to express a vast range of numbers, this comes at the cost of reduced precision. For most numbers, there will be some type of rounding. Using your example of 90.9, the closes 32-bit floating point value is 90.90000152587890625. So using scaled integers actually provides more precision than using floating point.

Keep in mind, communicating VFD's (supporting Modbus, for example) have been around for a long time. Back then 8-bit and 16-bit CPU's were common. These CPU's could not support floating point in hardware. Although 32-bit floating point calculations can be done in software, it is much more processor intensive to do this (even on 32-bit CPU's, let alone 8- or 16-bit CPU's), degrading the performance of the VFD.

Also, the raw values are very likely used directly by the VFD, not the scaled values. Using your example, commanding a speed of 90.9% requires sending a value of 909 to the VFD. The VFD does not internally convert this to 90.9, it simply uses the raw value 909. This simplifies the the coding and reduces unnecessary load on the CPU.