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 - jbrandall

Pages: [1] 2
1
Technical support / Re:Fine tuning some timing
« on: April 06, 2015, 06:55:47 PM »
Sorry about the 3 RPM confusion (see my second post).  That was how much I saw my RPM's vary in situation 'A' before I rewrote the code as per Gary's suggestion.  It is better now, but still not rock solid.

In fact I am only interested in speeds of 80 to 95 RPM's as we are using the number generated by the FMD to set a throttle on an engine, and anything below 30 RPM's means the machine is disengaged and coasting towards 0 RPM's.

"To confirm that the PULSEPERIOD can return a steady value, you can use a PWM output from the same PLC or from another PLC and feed the output to the FMD's PMON or HSC input and you can then read the period and you should be able to see a very stable PULSEPERIOD reading when you observe online." -- This line is interesting because at this time of year we are unable to actually test the machine in the field and so I built a simulator of sorts using a couple of spare Nano's.  My (limited) understanding of the PWM output is that it won't go as slow as .5Hz to 2.5Hz.  Am I correct?  If not please show me an example.

I hesitate to post this but the function below is what I use to generate the Nano output using a potentiometer to vary the voltage to ADC(1). (I wrote this a number of years ago and am not sure I understand it now)  It seems to work except for the variation described above as seen by the FMD.

REM set throttle - this runs every Clk:.01s
S=ADC(1)/18
IF S<50 S=50 ENDIF
IF S>200 S=200 ENDIF
T=6000/S
SETLCD 1,1,"Speed = "+STR$(T)
C=C+1
IF C=1 SETIO crank
ELSE CLRIO crank
ENDIF
IF C>S C=0 ENDIF

Thank you again for all the help!

John

2
Technical support / Re:Fine tuning some timing
« on: April 03, 2015, 06:08:21 PM »
Thanks Gary!  Because I still live in the 16 bit world I had to use one of the 26 (A to Z) 32 bit variables, but your suggestion helped a lot.  Then I averaged just 2 readings taken each second.  The most it wobbles now is 1 rpm and not often at that.  Good enough for me...

REM  do strokes per minute
temp1=PULSEPERIOD (2)
IF temp1<400000 OR temp1>2000000
THEN strokes_per_minute=0 REM crank stopped
ELSE strokes_per_minute=(strokes_per_minute+(60000000/temp1))/2 REM calc strokes per minute
ENDIF

In your second post you show a method using the interrupt feature.  The reason I moved to using the high speed counter and the PMON was that a friend that designs circuit boards told me to avoid using interrupts because of the overhead interrupting, pushing the stack, etc, and etc (of which I understand almost zero).  He said that built in counters are much better because they run independently of the other commands.  Not sure if this is true or not, but when I did use them, I got much more stable and accurate data (hence the added Nano).  The speed monitoring was the last hurdle (almost).  Now I'm wondering where I should put the above code; where it get done every scan or where it gets done every second.  Every second sounds like an interrupt, whereas every scan would just happen in the 'normal' course of things.

Further to your fist post:
Exactly how much time does your custom functions eat up?  
  I don't know...  It depends on what conditions it finds as it goes.
Do all of your custom functions execute on each ladder logic scan?  
  No - only the every scan routine which is short. Most are proximity sensor   triggered, some timer triggered.
Does any of your custom functions use the DELAY statement?
  Only the 1st scan - to hold a light on for 4 seconds.
Does any of your custom functions poll for some sort of response?
  Not that I know of. Mostly math.
Does any of your custom function use a time wasting loop of code?
  No.

It's just that a lot has to happen when the the crank reaches top dead center - reading, calculations, and responses (outputs). And it's just before top dead center that the Nano has to do it's counting - between 0 and 10 pulses, but fast.  The high speed counter on the FMD is counting pulses from a flow meter - nicely now!

Today's quirk is that when I turn on a PWM output, an analog input that I convert to 60 (pounds) jumps to 61!?  Probably not significant and I probably won't spend much time chasing it - it's just that I wish I understood more...

All of your responses help me learn  - Thanks
John

3
Technical support / Re:Fine tuning some timing
« on: April 02, 2015, 04:55:10 PM »
Thank you!  I wired everything up and it seems to work - much better than previously - with one minor problem.  I am trying to determine the speed of a crank arm that rotates about 90 rpm+/-.  A proximity sensors senses the passing of the arm and I use the following to calculate the speed:

REM  do strokes per minute
IF PULSEPERIOD (2)<400000 OR PULSEPERIOD (2)>2000000
THEN strokes_per_minute=0 REM crank stopped
ELSE strokes_per_minute=60000000/PULSEPERIOD (2) REM calc strokes per minute
ENDIF

This works and with very little load on the FMD will show the speed with 3 rpm's.  As I ask the FMD to do more (additional functions with some outputs) the speed range widens to maybe a 5 rpm range.  Adding more functions and a PWM output the speed range widens more and becomes somewhat erratic.  I have tried running the above calculation both at every second, and every scan and see little difference.  Any thoughts?  A better way to do it?  My concern is that I use the calculated speed to determine the PWM output, so random variance input causes random output.  

Again any thoughts/idea are muchly appreciated.

4
Technical support / Fine tuning some timing
« on: March 31, 2015, 06:42:43 PM »
I seem to have overload my FMD with too much to do and not enough time to get it done, so I am going to pair it with a Nano which will handle to most time sensitive routine with little to output.  However, the Nano will generate some numbers that the FMD will need.  So is it better for the Nano to write to the FMD or is it better to have the FMD read the Nano? (via MODBUS)  Using the Nano to write, I can control when it does so,  not true with a read by the FMD.  Does the 'writing' get done before the ladder cycle completes or after all the outputs have been set?

On a related subject; I am reading 64 variables from the FMD every 300 ms (via Host Link Protocol).  Is this affecting the ladder logic execution or are the communication functions separate from the main processor?  

I know I'm splitting hairs, but I'm getting some really strange results that can't all be blamed on 'noise'.  Thank you for any guidance anyone can provide.

5
Technical support / Re:high speed counter
« on: July 17, 2013, 07:57:19 AM »
follow up.  if I do PMOFF 2 the counter seems to work right.  the problem is that I need to monitor imput 4 for speed (rpm) and want to use input 3 for the high speed counter because of the interrupt feature.  is there any way to uncouple the linkage between input 3 and input 4?  I have no spare inputs to juggle so as to leave half a pair disconnected.

6
Technical support / high speed counter
« on: July 16, 2013, 02:58:11 PM »
why does my high speed counter start to count down when input(3) pulse stop coming?  all else it seems to work ok.  I do use PMON 2 to monitor input(4).  When that stops, the counter stops counting down.  What do I do??

7
Technical support / Re:timing issue or am I asking too much?
« on: April 05, 2013, 08:44:38 AM »
Found it!  Fixed it!!  Mechanical relay coil collapsing field causing phantom/extra pulse some how some where.  I've been warned about this for years but have never seen it.  Fixed with a diode.  Thank you for heading me in the right direction!

8
Technical support / timing issue or am I asking too much?
« on: April 04, 2013, 12:54:53 PM »
I have an FMD16-16 that is giving me fits.
Basically the plc has to monitor a shaft that is turning up to 90 RPMs and do some different things depending on other inputs.  I have an arm that passes a proximity sensor every revolution and I use the pulse period to calculate the speed of the shaft every scan.  While the shaft is making one revolution, another sensor is picking up 1 to 9 pulses very quickly. I think I have attached the program which has 31 rungs of ladder logic (not counting comments) and there are 22 custom functions which contain 55 IF/Then statements, some of which are nested.  I also read all 8 analog inputs, some 3 times quickly, as well as do several For I=1 to 10 Loops and control two PWM outputs.  Along with all that, I am asking for 64 bytes of data via a router and the hostlink protocol every 1/4 second.  I'm wondering if my problem stems from asking the processor to do all of it's work in the 2/3 of a second that it takes the shaft to turn one revolution.  What happens is that my RPM reading randomly goes way out of range and when I try to record it in memory, I sometimes get a double entry.
The problem started when I added this code: (and the function 'EndTrip' is called)
   IF juice_switch=1
      IF TESTIO(pickup) SETIO PumpOut SETPWM 2,5000,5 REM nozzle rate?
         IF injector_pump=1 SETPWM 1,7000,10 REM injector rate?
         ELSE SETPWM 1,3000,10  SETIO nozzles2 REM nozzles2 rate?
         ENDIF
      ENDIF
   ELSE CALL JuiceOff REM everthing off!
   ENDIF REM no juice

juice_switch is a DM memory location that I can toggle between 0 and 1.  pickup is input7.  Everything works fine up the point that I turn 'pickup' on WHETHER juice_switch IS ZERO OR ONE!??  Tried rewiring to input8 with the same results.  In my mind 'pickup' should not even come into play if 'juice_switch' = 0.

 I don't have a good concept of how fast a processor can do its calculations?  Is there a chance that I can't have the plc do everything I want in 2/3 of a second?  Is the PULSEPERIOD command interrupting the ladder logic?  It does recover and keep running, but the out of range RPM reading causes other problems.   How can I test this? What else could be wrong?

9
Technical support / Re:Trying to read a pulse period on FMD16
« on: February 19, 2013, 10:09:12 AM »
Thank you! Everything works as it should, and I apologize for being so stupid. Seems it is really, really, really important that each end of each wire be where it is supposed to be!!:(  

Unfortunately some people think blue wires should be ground and others think black wires should be ground...  Doesn't make any difference when you just connect them together as in a relay, but it sure makes a difference when you connect only one of them to an output.

Thank you again.

10
Technical support / Re:Trying to read a pulse period on FMD16
« on: February 18, 2013, 06:16:40 PM »
Yes temp1 is a 32-bit variable (T).

Nano running at 24v, FMD running at 12v, common ground.  They didn't play well together, so I put a mechanical relay between them. The led on input #4 blinks at about 60 per minute.  Should I be able to connect output 1 or 2 to the FMD input 4 with the different voltages?

"You can actually use the PWM output generated from the FMD PLC itself to trigger its input #4 (defined as PMON 2) and you should be able get stable readings."  I believe you, but I'm a little fuzzy on how.  Would I take my pulse generating routine and have it output to FMD #8 and then use ladder logic to have it turn input #4 on whenever output #8 is on?

Thanks for the help!

11
Technical support / Trying to read a pulse period on FMD16
« on: February 18, 2013, 03:04:18 PM »
I have upgraded from a nano to a FMD1616 and am trying to run a program that worked on the nano that I transfered to the FMD.  I am trying to read the pulse period on input #4 on every scan and I did do a PMON 2 on the first scan.  My statement is "temp1=PULSEPERIOD (2)" and when I monitor temp1, the numbers are all over the place, from 300 to 400,000 or more and sometimes negative.  I am using an old nano to trigger input #4 with what I believe to be a pulse every second; on for 2 tenths and off for 8 tenths.  My expectation is to see a number in temp1 around 1,000,000.  I do use input #4 to trigger other events functions.  What all am I missing??

12
Technical support / Monitoring a FMD
« on: February 01, 2013, 11:20:20 AM »
Is it just me or others having this problem:  In the past I have run several nano's and monitored them with my laptop running trilogi 6.??.  This year I had to goto FMD16-16's and upgraded to trilogi 6.45.  I'm using basically the same program as on the nano's and everything works as expected in simulation mode.  However, when I try to monitor/control the plc from my laptop, clicking on the inputs makes them act like one-shot inputs (they are not).  I see the input led light briefly, but that's it.  In the past, and in simulation mode, a left click acts like a momentary contact (on when held on and off when released), and a right click latches the input on.  Also the inputs work correctly via switches or sensors.  The problem seems to be in the monitoring program...

13
Technical support / Re:Nano-10 on 12V
« on: February 01, 2013, 11:09:24 AM »
I think the may actually run at 12v, but you may not be able to use the relays (outputs 3&4).  I discovered this when my battery went so low that the 12 to 24v converter couldn't make more than 12 volts.

See also my answer to a post last month (down 4 or 5)

14
Technical support / Re:Nano Power Supply 12v bumped to 24v
« on: January 21, 2013, 05:55:56 PM »
For what it's worth:  For 2 years I have used step up converters to run 2 nano1's each.  Mine came from virtualvillage, but sure look like the ones I just found on ebay:

http://www.ebay.com/itm/12V-to-24V-Step-up-Power-Converter-Module-DC-to-DC-/180702970695?pt=LH_DefaultDomain_0&hash=item2a12bc8347

I don't know all the technical stuff but they worked outside in the hot sun and powered a few additional relays.  I am currently upgrading to FMD 16-16's that run on 12 volts and have 10 or 12 nano's and 6 or 7 converters to sell. jbr651@gmail.com

15
Technical support / Re:Input #4 on FMD16-16
« on: January 21, 2013, 06:17:10 AM »
Ah yes, I did a PMON 2.  Silly me to think that referred to input #2!  Thank you, I think I can handle it now.

Pages: [1] 2