Internet PLC Forum

The stepper motor demo code does not need a user interface.

But, I added one to make this into a stand-alone test system.

I used a Weintek 7" HMI for the user interface.  The attached code will work on any of the Weintek HMIs. You can re-edit it to work on the smaller 4.3" displays.

Neal,

I am glad that you are making progress on your project.  Your code didn't get attached.  The Yabbse forum acts real funny with attachments.  They tend to vanish.

Stepper motors are deceptively simple.  The simple view is that for every step you issue the stepper will rotate a predicable amount.  Unfortunately the simple view is an illusion.  There are real-world issues with starting torque, holding torque, acceleration profiles, winding currents and micro-stepping modes.

1. The big issue with stepper motors is torque.  If a stepper is a rest and you issue a single step pulse, the stepper will move if the torque that it can generate is greater than what it takes to move the stepper's rotor and the attached load.  Torque is determined by the design of the stepper motor, the current that your stepper driver supplies and the step mode that your driver is using.

2. Once you can issue a single step pulse, the next problem is figuring out how long you have to wait to issue the 2nd step pulse.  You trying to figure out the maximum step rate without losing any steps.  If the stepper stalls and hums or if the system continues to move (inertia) after the last step pulse, you are stepping too fast.  You need to figure out this maximum step rate and cut it in 1/2.  This is as fast as you can operate without using acceleration / deceleration ramps.

3. Next you will run into mechanical resonance.  Stepper based systems can howl and scream at certain step rates and these are determined by a mess of physics.  To keep the noise down you can change the step mode of your controller (micro-stepping) rates like 1/4 or 1/8 might help quiet the system down. However, this reduces the starting torque and you will need to re-evaluate the maximum step rate without acceleration (step 2).  The other strategy is to run your system at higher step rates and you will need to figure out the acceleration/deceleration profiles to ensure that you do not lose position.

If you are using the stepper motor to move the door against gravity, you get into another stepper motor bit of physics, holding torque.  Most stepper motors use permanent magnets and this results in a motor resisting rotation when the coils are not powered.  Most stepper controllers, reduce the current through the coils when the stepper is not actively moving to reduce power usage. With no or low current it will be much easier for your load to move due to gravity.

If your system requires the stepper coils to remain energized to keep the door from closing due to gravity, you may need to use a much larger stepper and deal with the larger power supplies and the cooling issues to keep things from burning up.

I'd vote to counter balance the door.  This will increase the inertial mass of your system, but will require much less power to operate.  You might, also, consider a positive latching mechanism to hold the door open if living humans are going to use this gizmo.  I guy named Otis solved a bunch of these problems back in 1861.

Best regards,

Gary D*ckinson

Congo,

Let me explain what I was doing with this snippet of code:

' Reload HSCPV[1] with residual count value
'   the while loop is used to verify that HSCPV[1] was successfully reloaded
'
while (HSCPV[1] >= 100)
   HSCPV[1] = HSCPV[1] - 100      ' Reload counter with residual count value
endwhile

The HSC was programmed to call the CF in response to HSCPV[1] being equal to 100.  I wanted the value of HSCPV[1] to increment from 0 to 100 and when it hit 100 the CF that was called was to reload HSCPV[1] back to a value of 0.  The problem is that the CF is NOT called on the instant that the HSCPV[1] becomes zero, but is called at some time later and synchronized to the ladder logic.  

In my application the value of HSCPV[1] may have been incremented beyond the target value of 100 by the time the CF is called.  If the HSCPV[1] has been incremented to 105, this code would reload HSCPV[1] with the value of 5 so that 95 counts later HSCPV[1] will reach 100.  


   HSCPV[1] = HSCPV[1] - 100      ' Reload counter with residual count value


If your applications increments the HSC at a rate of 50 Hz, then the value of the HSC counter will change every 20 mS.  The HSCPV[1] will only be at 100 for 20 mS.  In order to poll the HSCPV using CF, you will have to poll at 2x rate that the HSCPV can increment. The minimum poll rate would be 100 Hz or once every 10 mS (Nyquist rate...).

If your application absolutely must perform your math equation only when the HSCPV[1] is exactly 100, 200, 300 ... this may be impossible to achieve with the PLC.  Remember that the HSCPV[1] is only at a given value for 20 mS!  And your PLC code must complete each scan in only 10 mS to ensure that you do not miss the critical HSCPV[1] value.

If your application would be OK with HSCPV[1] values of 100, 202, 300, 401, 505 ..., then I see no problem with using the PLCs to get this job completed.

I suggest that you do not use the HSCDEF interrupt mechanism, but simply call a custom function on every scan of the ladder logic. This code just compares the current HSCPV[1] against a 32-bit limit value stored in DM32[].  Each time you do the math just add 100 to the limit...

This is the simplest code that I know of that might solve your problem:

' HSCPV[1] Polled on every scan
'
' LimitValue is a 32 bit variable in DM32[]  Use a #Define to set this up
'
if HSCPV[1] < LimitValue
   return
endif

' Setup next LimitValue
'
LimitValue = LimitValue + 100

' Your code specific to your task follows:
'


This code simply allows HSCPV[1] to increment continuously.  There is no need to reload HSCPV[1] when the limit or target value is reached as this code does not use the HSCDEF to set up an interrupt function.  

The HSC counters are implemented in hardware and are 32-bit counters.  TBASIC works fine with 32-bit values and will treat the HSCPV as 32-bit signed variable (positive and negative values). When the 32-bit counter gets to the biggest positive number (134217727 decimal or &h7FFFFFF) the next count will be the most negative number ( -2147483648 or &H8000000).  The code that I presented should work fine.  However, I have been proven wrong on many occasions.

Best regards,

Gary D*ckinson

Congo,

Without knowing a lot more about what you are trying to accomplish, it is hard to give you very good advice on the usage of the PID algorithm.  

One of my systems use a variable speed pump to maintain a constant flow rate through a water filtration system. The pump is controlled by a VFD (variable frequency drive) that I can set the drive frequency from 00.00 Hz to 60.00 Hz.  This directly determines the pump RPM.

The other bit of trivia is that the VFD controls how quickly the pump can change speed (accelerate / decelerate).  In this case the VFD is set to take 10 seconds to go from 0 to 60 Hz.

The PLC code that uses the PIDCompute algorithm is called every 1/2 second, so the VFD can change a maximum of 3.0 Hz in 1/2 second.  I set the PID limit to 3.0 Hz as this is as big a change as the pump can make in 1/2 second.

The PIDDef statement is called once on startup:

PID_limit1 = 3.0      ' +/- 3 Hz limit
PID_P1 = 0.1800
PID_I1 = 0.0000       ' No Integral term
PID_D1 = 0.0000       ' No Differential term

PIDDef 1,PID_Limit1,PID_P1,PID_I1,PID_D1      ' Constant flow mode

This is the code that is called every 1/2 second to adjust the pump speed to maintain constant flow:

' Adjust pump speed to achieve target flow
'
D# = ProductGpmGoal - ProductFlowRate
if ABS(D#/ProductGpmGoal) <= 0.02
   ' error is within 2% of goal
   ' consider this close enough
   '  no adjustment required to pump speed
   return
else
   ' Adjust pump speed to get to goal
   '
   E# = PIDCompute(1, D#)            ' correction to pump speed in E#
   VFDTargetHz = VFDTargetHz + E#    ' This is the new speed for the main pump in Hz

   ' Enforce pump speed limits
   '
   if (VFDTargetHz > 60.0)
      VFDTargetHz = 60.0        ' Maximum pump speed before it throws a winding
   elif (VFDTargetHz < 0.0)
      VFDTargetHz = 0.0         ' minimum pump speed. Cannot go any slower
   endif

   SetIO ReqSetVFDSpeed    ' This RELAY invokes another custom function to set the VFD speed
endif

Please note the following:

• The variable, ProductGpmGoal, is the target flow rate
• The variable, ProductFlowRate, is the current flow rate
• If the ProductGpmGoal and ProuctFlowRate is within 2% of each other, no adjustments are made.  This is close enough for my client's application.
• The variable, E#, is generated by the PID algorithm and I add this computed error term to the current VFD speed to determine the next VFD speed.  This eliminates the need for the "I" or integral term for the PID algorithm.
• I bound the next VFD speed variable, VFDTargetHz, to stay between 0 and 60
• The RELAY, ReqSetVFDSpeed, invokes a Custom Function to send then value VFDTargetHz to the VFD to adjust the pump speed   

This may give you a hint of what is involved in actually using the PID algorithm.

Gary D*ckinson

Lorne,

You are right that Status(18) returns hours, minutes and seconds as a single integer. There are two reasons that Status(18) is very important:

• It simplifies your code when testing to see if the current time is equal to some target time.  Otherwise you have to make tests that involve TIME[1], TIME[2], and TIME[3].
• It solves a problem with CF reads of the TIME[] registers in the PLC firmware. The registers update asynchronously to the execution of custom functions.  As an example, if the PLC's RTC is at 23:59:59 then it is possible to observe the time registers going through all sorts of incorrect values before getting to 00:00:00.

It is possible to observe the following transitions: 23:59:59 -> 23:59:00 -> 23:00:00 -> 00:00:00
[/list]

The following test code can be used to avoid the illogical  TIME/DATE register transitions:

' AvoidRipple
'
while 1
   ' read all TIME[] and DATE[] registers, one time
   '
   DM[301] = TIME[1]   ' Hours
   DM[302] = TIME[2]   ' Minutes
   DM[303] = TIME[3]   ' Seconds
   DM[304] = DATE[1]   ' Year
   DM[305] = DATE[2]   ' Month
   DM[306] = DATE[3]   ' Day
 
   ' re-read the TIME[] register and verify that they did not change
   ' from the previous set.  The whole point of this exercise is to
   ' detect and discard erroneous readings that can occur because the PLC
   ' firmware is constantly updating these register.  It is possible to
   ' observe the following transitions:
   '
   '  23:59:59 -> 23:59:00 -> 23:00:00 -> 00:00:00
   '
   if      DM[301] <> TIME[1]
      continue
   elif    DM[302] <> TIME[2]
      continue
   elif    DM[303] <> TIME[3]
      continue
   elif    DM[304] <> DATE[1]
      continue
   elif    DM[305] <> DATE[2]
      continue
   elif    DM[306] <> DATE[3]
      continue
   else
      exit
   endif

endwhile


If you directly access the TIME registers you need to:

• Only use Status(18)
• Never read/write them if there is any possibility that the RTC will update the registers.  Say only at time xx:xx:30.
• Read all registers as a set and then re-read all of the registers until you get the same values twice in a row.
• Shut off the RTC mechanism during CF access to the registers.

Please note that the same issues happen with the DATE[] registers.

Please be aware that if you set the RTC registers it is possible for the registers to be changed while you are updating.  You should either shut down the RTC during the writing or following the write operations re-read the registers to verify that you have set them without interference from the PLC firmware.

Gary D

Neal,

Sounds like your are on a good track.  Don't let the size fool you. Most SSRs are sold without heatsinks.  If this is the case with the OMRON units, you may have to bolt the SSR to a big heat sink to ensure that it does not fry.

If your application has a big thermal mass or your application can tolerate a few degees of temperature change, you might not need much more  than on/off control of your heater.  Read "cheap SSR".

The PWM mechanism supported by PLCs is not useful for SSR as the PWM frequency is two high.  It is possible to use a pair TIMERS to build a low speed variable duty cycle system for SSRs.

Best regards,

Gary D*ckinson

Lorne,

If you are talking about the servos used for radio control models, the answer is yes.  The position of these servos is determined by the width of a pulse that is sent to the servo. Most servos are centered when the pulse width is 1.5 milliseconds.  The typical range of pulse widths for these servos is from 1.0 to 2.0 milliseconds.  Your 180 degree servo may require a bit wider range of pulse widths to turn the full amount.

The Fx series PLCs all support some number of PWM (pulse width modulation) outputs.  It is possible to program these outputs to produce the pulses for RC-type servos.  The PWM mechanism can handle the required range of pulse widths and repetition rates expected by these servos.

You will have to deal with the fact that the PLC's PWM outputs go from 0 to 24V and the servo's inputs are from 0 to about 5 volts.  There are notes in the user manuals in chapter 11 that shows typical circuits to interface the PLCs to RC-type servos to solve the signal level issues.

As an alternative to using the PLC's PWM outputs, you can purchase low cost RC-servo controllers that can be connected to the PLC's RS232. The Pololu "Serial 8-Servo Controller" is a widely available controller.  This controller can handle 8 servos at the same time.  The PLC sends a 5 or 6 byte command via its serial port to position the servos.  

A nice thing about using an external controller is that you can set a parameter that determines how quickly the servo moves.  A typical servo moves about 60 degrees in about 0.2 seconds.  If you would like the have the servo move more slowly, say take 2 seconds to move 60 degrees, it is easy with the external controller.  If you need to do this with the PLC, you will have to change the PWM outputs several times with delays between each change.  This is possible to do with the PLC, but it is a little complex (fun?).

Best regards,

Gary D*ckinson