Mitsubishi FX-2n FSTLP question

[monkeyhead]

Hey all, looks like the forum got updated since I was last hanging around here (either that or it's just been a long time.)

Anyway, a little background on my question. We've had this machine that for years has bothered me. Theres a product feeder that has seperate lugs for each order to be processed. A SICK photoelectric prox eye detects (well it tries anyway - prox eyes and clear plastic don't always work so well) the package and tells the machine to feed a carton for the order.

The behaviour that has always driven me crazy is that if the eye flickers at all in it's reading window, the product gets ignored causing problems down stream.

The whole machine is based around an encoder (0-359). In the machine's setup menus, you can adjust the window in which the product sensor will look for the product so the lugs don't get picked up as they pass the sensor.

I finally got hold of GX developer and found the section in the ladder where this is handled. The guy who wrote this used the FSTLP instruction.

Here's a simplified example of what it looks like:

     M13

  ---||------------[SFTLP X030 M520 K5 K1]--

  

  M13=Bit that's on during the adjustable reading window

  X030=Photo Sensor input

  M520=Bit that's set to feed a carton

  

So after reading up on the SFTLP instruction, I'm assuming that it only does the bit shift the first time it scans and M13 is true. This seems bizarre to me, because A. Why even have an adjustable reading window when it only checks it as soon as it opens, and B. This is inconsitent with what I've seen on the machine. I've fought with the stupid photo eye for years. I started out as an operator on this damn machine and I swear that everytime the stupid thing flickers off while product is passing, it won't pull a carton.

So after all that, my very simple question is am I analyzing the FSTLP instruction right?

 

[REZAR]

pswell, i guess the problem is'nt on the SFTLP.
i prefered investigate why the photo eye is flicker.
is it b coz:
1. bracket isn't strong enough?
2. photo eye is not aligned?
3. position of photo eye isn't nice?
4. photo eye is not solid state?

i have been there, but not with SFTLP. i spend 1 month to decide remaking bracket for photo eye.

would you let us know the end of this story?

ps. yup, this site is fresh.

 

[monkeyhead]

The photo sensor is just poorly suited for the application. I've never had much luck with proximity eyes when the product material varies a lot. The product is a mix of media ranging from cd's to dvd's to vhs tapes.

I actually plan to replace the sensor with a transmit/recieve combo, but that's going to require taking the machine down long enough to cut a hole in the other side of the product feeder. So i've avoided it up to now.

I'm still curious about whether or not I'm interpreting the function of this bit shift correctly.

 

[Goody]

---||------------[SFTLP X030 M520 K5 K1]--



M13=Bit that's on during the adjustable reading window

X030=Photo Sensor input

M520=Bit that's set to feed a carton

The flickering eye really shouldnt make much difference apart from (Maybe) if it is caught at exactly the same instant as m13 goes true

M13 is responsible for the shift.
If when it comes true and the PCell is detecting, a '1' will be shifted left. If it is not detecting, a '0' will be shifted left.
In this case through 5 bits M520 to M524

While m13 is on, a flickering X30 will not add anything to the stack
It will only shift again when M13 has gone false then true again

 

[Unregistered]

Awesome... Thanks for that.

Sorry for the unregistered post, I'm at work and can't remember my password.

-Monkeyhead