Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - nealbert

Pages: 1 [2]
16
Technical support / Re:Stepper motor homing sequence not behaving
« on: May 08, 2018, 04:47:19 PM »
Gary, Lorne,

Sorry for the slow response, but I've been out of town for the past week taking care of some family business.  Anyway, thanks for the feedback and suggestions.  I did install a counter balance system to the door just before I went out of town.  This solves the problem of the door dropping like a rock when we lose power.  But, As y'all pointed out, it also lightens the load on the motor while moving (less chance of missing steps) and while holding the door closed (less chance of motor burn-out).

Right now there is only one limit switch and it is tripped when the door is closed.  The operator must Home the door one time when he/she first powers up the machine.  After the initial "Homing" I ignore the Limit Switch.  Since I am running open loop that is is a bit of a risk that the motor could miss a step or two.  If we find that the door loses steps then I could make the door "re-home" every time it closes.

So far the machine is working fine without a second Limit Switch (at the fully open position).  During operation, the door is never fully open.  The door is either fully closed or in some intermediate position between open and closed.  I might add a Limit switch to the fully open position just as an indicator that there was a mechanical failure ( belt broke, motor died, etc).

This machine is a prototype so we have lots to learn about it's performance.  But, just in case, I've already purchased a second stepper motor with a brake and a third stepper motor with a 50:1 gear box.  Better safe than sorry.

Neal

17
Technical support / Re:Stepper motor homing sequence not behaving
« on: April 25, 2018, 02:14:04 PM »
Gary,

Thanks for the feedback.  I took your suggestion and inserted "While TestIO(Limit_Switch) = 0" in place of my "While Input[1] = 0"  Unfortunately, that didn't work either.  Hitting the Limit Switch did not stop the stepper motor.  So, taking your bullet points into consideration I re-wrote the code as attached.  This DOES stop the stepper motor when ever the Limit Switch actuates.  Hooray.

Basically, I separated the different functions into multiple CF's.  STEPSPEED is now defined in the Initial Scan.  STEPSPEED and SETSTOP/STEPHOME are in their own CF.  No more polling an INPUT from within a CF.  I also got rid of the While loop which was causing problems before.

I was planning on adding another STEPMOVE command to traverse my door quickly towards the home position, then slow down as the door moves towards the Limit Switch.  Fortunately, in my application the door is already moving slowly and is also moving against gravity, so when the stepper motor stops, the door stops very quickly.  My biggest concern was overshooting the Limit Switch due to system inertia and encountering a hard stop.  I never considered the voltage spike that could be generated by a high inertial load over-driving a stepper motor.  I have not encountered that, yet, but it's good to know.

Thanks again,
Neal Cooper

18
Technical support / Stepper motor homing sequence not behaving
« on: April 23, 2018, 01:32:33 PM »
I wrote a little stepper motor homing routine and have found that it's implementation is anything but routine.  My application is a small vertical elevator that is moving a door.   When my device is at rest (everything de-energized) the door is at the bottom of travel (due to gravity) and is fully open.  When I energize the device, the first thing the operator needs to do is home the stepper motor.  (For safety sake I chose to force the Operator to start the Homing sequence by pressing a button on the HMI rather than initiating an unannounced homing sequence when the device is powered up.)   In this case Home means the door is fully closed.  The stepper motor needs to drive about 400 steps to close the door.  The number of steps is approximate due to manufacturing tolerances and the presence of a soft gasket on the face of the door.  Hence, the need for a homing/limit switch.

The routine I wrote is in the attached "Homing.pc6".  My idea was that I would start the Homing sequence by touching a button in the HMI (Relay1 or Start).  This starts the "Homing" Custom Function. I first set the step motor speed using the STEPSPEED command, then jump into a while loop that is running the STEPMOVE command.  I would exit the While look as soon as the door tripped a limit switch (Input[1]).  Once I exit the While loop, I issue a STEPSTOP command to immediately stop the step motor, then follow that with a STEPHOME command to set the new Home position.  At least in theory it sounded good.

Even on the iTrilogi 6 Simulator everything looks good.  Clicking on Relay 1 starts the stepper motor.  Clicking on Input 1 stops the stepper motor.  Great.   EXCEPT, I discovered that clicking on ANY input, stops the Stepper motor.  Hmmm! ???

So I moved to the hardware and discovered JUST THE OPPOSITE...The step motor starts like it should when I activate Relay 1 via the HMI.  However, closing the Limit Switch/ Input[1] (or any Input) does nothing.  The step motor keeps on going until it reaches a hard stop.  Or, you cut the power.  Ouch!

The Simulator and the real hardware do share one common trait...if ANY Input is closed when I hit the START Button (Relay 1) then the Step motor will NOT start.  Well, I guess I can throw out my Normally Closed E-Stop!

I've tried this code on iTrilogi versions 6.47 build 05, 6.52 build 03 and 6.52 build 05 and get the same results on all 3 versions.

I'm open to any and all suggestions.  I'm not too worried that the Simulator and the real world don't behave the same.  It would be great if they did, but I can work around that.  The main thing I need is a working, repeatable, reliable Homing Sequence.   At his point I don't know if most of my problem is with my logic or the software.  

19
Technical support / Re:SetDimmer
« on: February 19, 2018, 08:57:56 AM »
Gary,

Thanks for the reply.  I went back to the "SetDimmer" Help screens and finally noticed the asterisk...

*{Applicable only to F-series PLC}

I'll pay more attention next time.

I've got 2 Omron proportional SSR's on order now.  I've also got a RS485 controller light dimmer that I bought a couple of months ago for a backup.  Good for 240VAC, single phase at 16 amps.  It's called a RS485 Leading Edge Dimmer and is made by Krida Electronics.  Gonna wire it up today and see how that works with my 2000 watt IR element.  Only problem is it's size.  At 3.2 x 5.1 x 2.5, it's much bigger than a SSR.  As usual my 5 lb bag already has about 9.5 lb of crap in it.  Aah, that's why they call it Development.

Thanks again,
Neal Cooper

20
Technical support / SetDimmer
« on: February 16, 2018, 01:05:09 PM »
Help.  I am trying to vary the output of an infrared heating element and it looks like the SetDimmer function might work for that application.  I'm coming out of Output 8 of an FMD88-10, to a SSR, then to the quartz element.  I've created a Function Block with the command "SetDimmer, 4, A" where A = DM[1].  DM[1] varies form 0 to 156 and is controlled by a slider bar on my HMI.  I've tried different ladder and Function Block configurations, but cannot seem to get anything to work.  Output 8 never turns on, no matter what the value of DM[1].

The i-Trilogi Help says SetDimmer "will send a short trigger pulse to the SSR to turn it on".  So, that means, SetDimmer needs to be inside a loop??

I've searched the Forum for "SetDimmer" and found nothing. (Does nobody use this Function??) Can someone please provide some ladder and/or Function Block code that shows how SetDimmer is supposed to work?  Do I need a zero-crossing SSR for SetDimmer to work?

Many thanks,
Neal Cooper ???

21
Technical support / Change TimerSV with Wientek MT8050iE
« on: October 20, 2017, 09:28:13 AM »
I am using an FMD88-10 and Weintek HMI MT8050iE in an oven application. I have the HMI programmed so the operator can monitor and change the SetPoint Temperature, Actual Temperature, conveyor speed and the condition of various fans.  Changing those values from the HMI is relatively easy since I'm only dealing with integer and Data Memory variables.  But, I have 3 heating elements that operate for different times.  They all turn on together, but turn off at different times. Currently I use the TimerSV that is assigned to each Timer when it's created in i-Trilogi.

I want to have the ability to change the TimerSV from the HMI.  I assume I need to use the SetTimerSV function.  However, according to the TL6 Reference Manual "the new S.V. are only stored on RAM-shadowed CPU flash memory and is normally volatile unless..."  OK, requires an extra step to write the data to CPU flash memory.  No big deal.    However, I get a bit nervous when I read things like "Programmer should therefore use this command sparingly".

On the HMI I would also like to have a "CANCEL" and "SAVE" button to give the operator the option to save the new S.V. values or abort the action.  Pressing the "SAVE" button could trigger a Special Function in the PLC to write new values to the TimerSV.  Can the "CANCEL" feature be implemented entirely in the HMI?
 
Is there and easier (better?) way to change the SV of a timer from the HMI than using the SetTimerSV function?  According to the Comments in Section 12.73 of the TL6 Reference Manual a "TBASIC custom function can start a timer by setting it's TIMERPV[] variable to any integer value between -1 (reset timer) and 9999 so it is not necessary to change the timer S.V."  Really?  How does that work?  Examples?

Pages: 1 [2]