Anyone with Siplace feeder knowledge?

[Bernd Walter]

I've bought some used Siplace feeders on Ebay for a good price, because Mark Harris did some videos on their functionality.
Mine are almost identical, but with an older design PCB.
Thanks to Mark I had known that they run on 30V DC and I'd managed to find out what pins they are.
On the dual lane feeder I'd tested one lane didn't work reliable with 24V, so full 30V is required.
The protocol is something unknown serial via optoisolator.
The feeders have 2 buttons, one with LED per tape (they are dual lane).
The yellow button with the LED activates the cover tape motor during setup.
The LED will start to flash if the cover tape isn't working correctly and the motor will stop - you have to push the button to release from the error condition.
The green button advances the tape, pushed opens the shutter and released advances the tape.
So far I'm happy, because I can get the feeder to work without changing the electronics, just by using a relay on the green button.
I might change the electronic later anyway, but since I can't find out what type the PCB connectors are, I'd have to change them all.
However the button advances the tape by full 4mm, so it won't work for 2mm tapes, like 0402.
In Marks videos it is clear that they could do 2mm as well.
I've tried to play with the buttons, but couldn't find a configuration mode.
Does anyone know how they are configured?
Or is it normal that the button always advances 4mm and 2mm is only available via machine command?
Otherwise they seem to be pretty good feeders, if you can get them at a good price.
The Yamaha CL feeders are a bit easier to load and have a spool holder, but otherwise I like the Siplace.

[Karl Zeilhofer]

Have you tried to get infos from the manufacturer?
It seems to be a time intensive workaround, just simulating button press with a relay. And as you found out, you even cannot use all it's features.
Perhaps this feeder uses very simple commands. I'm sure, you can find a software, which brute forces all possibilities, if you really dont get any info from the manufacturer.

[Bernd Walter]

On Friday, October 27, 2017 at 5:03:08 AM UTC+2, Karl Zeilhofer wrote:

Have you tried to get infos from the manufacturer?

No and I'd be extremly surprised if it is anything else then wasting time.
I know that several PDFs for the machines exists, but none is available on the net.
Not even a simple manual.
There is usually a reason for that.
Siemens also isn't well known to hand out protocol data unless you are a big partner.
Well, this isn't Siemens anymore, but I assume the same people.
 

It seems to be a time intensive workaround, just simulating button press with a relay. And as you found out, you even cannot use all it's features.

Wiring a relay is a rather quick solution.
The contacts are very accessible and the feeder responds quick to the buttons.
It is only a temporary solution until I find the time to retrofit them with a different electronic.

Perhaps this feeder uses very simple commands. I'm sure, you can find a software, which brute forces all possibilities, if you really dont get any info from the manufacturer.

Brute forces all possibilities on a single signal wire?
Seriously?
This is probably UART, but RX only, so I can't even know if it uses ASCII and my bps rate is correct, because it can't even give me any kind of feedback.
I don't have a full machine to sniff the data either.
Sounds more reasonable to reverse engineer the firmware - it is an 80C32 with an external 27C256, so unprotected binary.
Nevertheless - I won't spend days to go through 32K binary if I don't want to keep the PCB forever.
I'm not even going to try my own firmware on the controller, because there are different PCB versions out there, which look like they may require different firmwares.
But if however, someone familar with the feeders knows if some buttons can make them go into 2mm mode, the temporary workaround would be more functional.
I'm not asking someone to spend time to investigate.

[Bernd Walter]

On Friday, October 27, 2017 at 5:35:17 AM UTC+2, Bernd Walter wrote:

On Friday, October 27, 2017 at 5:03:08 AM UTC+2, Karl Zeilhofer wrote:

Have you tried to get infos from the manufacturer?

No and I'd be extremly surprised if it is anything else then wasting time.
I know that several PDFs for the machines exists, but none is available on the net.
Not even a simple manual.
There is usually a reason for that.
Siemens also isn't well known to hand out protocol data unless you are a big partner.
Well, this isn't Siemens anymore, but I assume the same people.
 

It seems to be a time intensive workaround, just simulating button press with a relay. And as you found out, you even cannot use all it's features.

Wiring a relay is a rather quick solution.
The contacts are very accessible and the feeder responds quick to the buttons.
It is only a temporary solution until I find the time to retrofit them with a different electronic.

Btw.: I've just found a feeder with one lane doing 2mm steps.
So it is configured in the feeder somehow.
For me this just means, that I could use it single or dual step for 2mm and 4mm.

[Marek T.]

I was breaking different protocols in my career but having no host you have no chance, even with this well protected encrypted communication is often not to break.
I would think to replace this 80c32 processor with new one containing your code (and your protocol) than debug ROM and found the original protocol...

[Cri S]

The protocol is rs232 with 30v on single line .

Il venerdì 27 ottobre 2017, Marek T. <marek.tw...@gmail.com> ha scritto:

I was breaking different protocols in my career but having no host you have no chance, even with this well protected encrypted communication is often not to break.
I would think to replace this 80c32 processor with new one containing your code (and your protocol) than debug ROM and found the original  protocol...

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/80d01777-63ce-40d2-b495-87064c3034bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marek T.]

Do you mean there is 0-30V level on the data bus?? And txd only?

[Bernd Walter]

On Friday, October 27, 2017 at 12:07:54 PM UTC+2, Marek T. wrote:

Do you mean there is 0-30V level on the data bus?? And txd only?

30V signaling is very plausible.
I've measured a 15k resistor between connector and opto, which translates to 2mA.
Also UART is very plausible, since the 80C32 has HW support for that and it would be silly to use something else.
Later feeder of the S-series have some kind of bidirectional transfer.
In my model only 4 wires are used - 2 power, plus 2 for the opto, but the connector to the machine has 7 pins.
I doubt it is encrypted, but since I don't have access to a machine all I could do is using the firmware binary.
I'm not going to do this.

[Niels]

Hi Bernd,

Can you send me the EPROM binary? I will try to recover the protocol, if you're interested.

Regards,

Niels.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bf8a88d8-5b9e-4bf7-870a-1b4a6b490d82%40googlegroups.com.

[Bernd Walter]

On Friday, October 27, 2017 at 10:22:44 PM UTC+2, Niels PA1DSP wrote:

Hi Bernd,

Can you send me the EPROM binary? I will try to recover the protocol, if you're interested.

Hi Niels,
 thank you for the offer, but I've decided for myself that it would be too much work.
I havn't done a lot on x51, but it is something I could do on my own if I really wanted.
I'm currently waiting for an PLCC adapter to read the EPROM.
It is not that I'm not curious to take a quick look into the code at least ;-)
I will mail you a copy, but only spend time if you want to know it for yourself.
Wouldn't be fair to let someone else do the work just because I'm too lazy.

Btw.: If anyone has to repair those things, I've had a lot of fun today.
My 8 feeders came for 20 EUR each, plus shipping.
They were sold as non functional - functional offers are in the 100-150 EUR range.
Of course a few had failures.
I now have 7 functional ones, with the 8th not tested yet, so likely this one will be functional as well, but it's not at home.
There had been three major failure modes.
Loose screws - lots of them, many of them required a fair amount of teardown to reach, but nothing difficult.
And components in the tape advancing gearbox, blocking the motor.
This is super easy to fix on the right lane and requires removing one lane from the base block in case
of the left lane.
The firmware quickly notices a blocked motor, so risks of having a blown motor is rather low.
The shutter also tends to stick, mostly because it uses a dampening foam, which wears over time.
Since it sticks in open position, I didn't bother to fix this.
One lane had a problem, which wasn't so fine - a gear was scratching on the cover plate, because it
was mounted in the wrong position.
Opening the set screw and relocating it was easy, but it also defines the pick location, so you will
loose the feeder calibration.
I don't consider this as a common failure mode.

Regards,

Niels.

On Fri, Oct 27, 2017 at 9:08 PM, Bernd Walter <be...@bwct.de> wrote:

On Friday, October 27, 2017 at 12:07:54 PM UTC+2, Marek T. wrote:

Do you mean there is 0-30V level on the data bus?? And txd only?

30V signaling is very plausible.
I've measured a 15k resistor between connector and opto, which translates to 2mA.
Also UART is very plausible, since the 80C32 has HW support for that and it would be silly to use something else.
Later feeder of the S-series have some kind of bidirectional transfer.
In my model only 4 wires are used - 2 power, plus 2 for the opto, but the connector to the machine has 7 pins.
I doubt it is encrypted, but since I don't have access to a machine all I could do is using the firmware binary.
I'm not going to do this.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

[Bernd Walter]

On Friday, October 27, 2017 at 6:00:57 AM UTC+2, Bernd Walter wrote:

On Friday, October 27, 2017 at 5:35:17 AM UTC+2, Bernd Walter wrote:

On Friday, October 27, 2017 at 5:03:08 AM UTC+2, Karl Zeilhofer wrote:

Have you tried to get infos from the manufacturer?

No and I'd be extremly surprised if it is anything else then wasting time.
I know that several PDFs for the machines exists, but none is available on the net.
Not even a simple manual.
There is usually a reason for that.
Siemens also isn't well known to hand out protocol data unless you are a big partner.
Well, this isn't Siemens anymore, but I assume the same people.
 

It seems to be a time intensive workaround, just simulating button press with a relay. And as you found out, you even cannot use all it's features.

Wiring a relay is a rather quick solution.
The contacts are very accessible and the feeder responds quick to the buttons.
It is only a temporary solution until I find the time to retrofit them with a different electronic.

Btw.: I've just found a feeder with one lane doing 2mm steps.
So it is configured in the feeder somehow.
For me this just means, that I could use it single or dual step for 2mm and 4mm.

Ok - I've managed to find some chinese info, since I can't read chinese it was a rough ride.
https://wenku.baidu.com/view/091be6e8e009581b6bd9eb5a.html?mark_pay_doc=2&mark_rec_page=1&mark_rec_position=2&clear_uda_param=1

One thing I've already found out is that in 4mm mode you can advance by 2mm.
Press green and holding it down, press yellow and holding it down, release green and the tape get advanced by 2mm.
While still holding yellow down you can press green multiple times.
This, I assume, is to 2mm align the tape in 4mm mode.

Configuring 2mm/4mm mode:
You need to have a tape loaded, so that the yellow LED doesn't flash.
This is the magic trick why I hadn't manged to find this myself, since I'd always tested without tape.
And trust me, I had tried the right combination.
Press green, wait until the shutter closes again and keep holding it down.
Press yellow once for 2mm (twice for 4mm, later tripple lane 8mm feeders can also do 8mm).
Release green.
The yellow LED should flash once for 2mm, or twice for 4mm.
The feeder has a small I²C EEPROM (X24C44 in my case) to store the configuration.

[n.a.m...@gmail.com]

Hi Bernd,

I will gladly reverse engineer it; I like a challenge. It would also benefit the community to be able to use Siplacer feeders without having to replace the electronics. I do hope the protocol is similar between models, but we'll have to see :)

I look forward to a .bin file.
Would it be possible to make a couple of photographs of the PCB? This would help me figure out the connections to the CPU.

Regards,
Niels.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/03985c97-751c-4c3d-b313-94f8be9354f3%40googlegroups.com.

[Bernd Walter]

On Saturday, October 28, 2017 at 4:37:45 PM UTC+2, Niels PA1DSP wrote:

Hi Bernd,

I will gladly reverse engineer it; I like a challenge. It would also benefit the community to be able to use Siplacer feeders without having to replace the electronics. I do hope the protocol is similar between models, but we'll have to see :)

I'm pretty sure they have something in common.
I think for reverse engineering my older PCB version is very fortunate, because it has an external EPROM chip.
Marks later revision, with the same mechanics, used a controller with internal ROM, which probably is read protected.

I look forward to a .bin file.
Would it be possible to make a couple of photographs of the PCB? This would help me figure out the connections to the CPU.

I will remove a board and take pictures, when I have to PLCC adapter, which will be next weekend.
In the meantime you can take a look at marks pictures:
http://www.markhphoto.com.au/Siemens-Siplace-80-F3/
He also took pictures of his own retrofit board, but he used new connectors.
So far I couldn't find out what the original PCB connectors are.
My PCB version has many differences.
It is using an optoisolator for the data, which Marks board doesn't.
both PCB versions have an X24C44 EEPROM chip.
Mine additional have an 74HCT245, 74HCT574 and an 74HCT573.
The drivers use different transistor.
The 74HCT573 is for the address demultiplexing to connect the EPROM of course.
The HCT245 and HCT574 point to additional IO-Pins used.
This isn't the case with Marks board.
I think he said in one of his videos that it is an Atmel 8051 compatible.
You should definitively watch his videos about those feeders:
https://www.youtube.com/watch?v=ql0o4lEWL2A
https://www.youtube.com/watch?v=Y3OMtkqk9J0
Another difference is that my PCB has an 7805 and his a switching regulator.

I will start designing a 3D printed feeder mount plate as a basic start.
The front guide pins are 5mm diameter and I think as a 3D printed version they break very soon, as you are intended to slide against them, but I will do it anyway.
When it works I will decide if I go for CNC alu or 3D print, both with steel press fit guide pins.
The size requires a 270 to 300mm printbed in one dimension at least.

[n.a.m...@gmail.com]

Hi Bernd,

Thanks for the information. Mark's photos and videos are very helpful.
My intention is to make a small 8051 simulator and load the code into that.
I already have a basic framework I made for the DIY RC2014 Z80 based computer that I can re-purpose for this.
With this, I should be able to get some idea of the UART setup quite quickly.

Regards,
Niels.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/faa0d438-5225-4910-b283-cb409aac08a7%40googlegroups.com.

[Bernd Walter]

On Sunday, October 29, 2017 at 12:49:29 AM UTC+2, Niels PA1DSP wrote:

Hi Bernd,

Hi Niels,
 I've send you the firmware via direct mail.
What I've just found out is that I was wrong about the interface.
The PCB is hard to follow, because it is multilayer.
The data connector on the PCB is from the PCB border:
 brown +30V
 white GND
 yellow TXD via optoisolator +30V or open, MCU low => +30V
 green RXD via transistor +30V => low on MCU RXD
So in fact it is a bidirectional UART based data transmission.

I've loaded the firmware into ucsim - not that familar with 8051 family and new to the simulator though.
With verbose I can see that time 0 and 1 trigger regularily, so a good sign that the firmware seems to start somehow.
The uart and timer2 config shows:
0> i h uart[0]
uart[0] 8 bit UART timer clocked (timer2) MultiProc=none irq=en prio=0
Receiver ON RB8=0 irq=0
Transmitter TB8=1 irq=0
0> i h timer2[2]
timer2[2] 0xffde baud RCLK TCLK 0xffd9 timer ON irq=0 ? prio=0
If I got is right this means the UART (12MHz crystal) runs at 9600bps.
Now when it come to actual data transfered things get harder to analyse.
Since there is no text beside a firmware info (12.12.94    mit FSZ Testroutine), decoding the protocol actually means tracing the code.
There is no guess work possible based on ASCII strings.

[Marek T.]

Hi Bernd,

11.059200MHz (or multiple like 22118400) is used for C51 architecture to get exact RS232 speeds like 4800, 9600, 19200 etc.
If they used 12MHz quartz it means they have shity timings on RS232 or they use some not PC common RS232 speed. Sometimes people do it if don't need to talk with PC or just want to make it harder to complicate protocol cracking. I had situation like that few times so it's not guessing but practice. If it is so you will maybe need to build converter containing two linked processors - one to talk with PC on some typical speed and second to talk with feeders on their specific speed.

[Bernd Walter]

Yes - it can't be exact, but I got that value from a Philips datasheet table for 12MHz.
http://hxc2001.free.fr/minitel/80C3X_DS.pdf
Table 4 on page 13.
Sounded plausible, so I just trusted it.

Now doing the maths:
0xffd9 is 65497
12000000/(32*(65536-65497))
9615.38461538461538461538
Only 0.16% off.
Should be more than close enough to work.

[Daniel Dumitru]

instead of reverse engineer binary code, wouldn't be a good idea to put a sniffer/logger on a working feeder/machine ?

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/de751601-e392-481a-b3e0-54baa336f22f%40googlegroups.com.

[Bernd Walter]

On Friday, November 3, 2017 at 11:18:37 AM UTC+1, Daniel wrote:

instead of reverse engineer binary code, wouldn't be a good idea to put a sniffer/logger on a working feeder/machine ?

No, because I would have to buy a machine to do this ;-)
Well - I know where some machines are, but I'm not sure they will let me sniff the communication.

I've already found out a fair bit about the protocol, just by reading the code.
I have to hook up a real feeder however, since the simulator has no mechanic and missing sensors.
You simply can't see what a command does on the mechanic with the simulator.
But now that I know the communication is bidirectional everything makes way more sense, because I've
puzzled how they calibrate the feeders as doing so in hardware looks impossible.
The feeders have an EEPROM and I know that newer feeders can be calibrated in software, by configuring the pick location offset.
This is most likely also the case with those feeders, which means that a static pick locations only works if you don't change feeders.
This is the first model, which works electrical only.
Siemens had at least 3 different older feeder generations.
All of them are shutterless, 4mm only and could be actuated using a push-button via a pneumatic actuator mounted on the siplace head.
The oldest is mechanical only, the later ones have 2 different style connectors, one of them is the same to all the later models.
I expect to get my hands one some of those with the same connector.
So far I only know that they work fundamentally different, but are mounted exactly the same way on the machine.

[SMdude]

Hmmm, watching this with much interest :D
It seems that at this point in time there is a good cheap supply of these
used feeders about.
The one thing that is missing from my machine is auto tape feeders and that
really chews up my time keeping on top of the strip-feeders.
Once I can load my reels onto my machine, I am very confident that I can
press start and walk away and come back when my boards are placed, which I
have been able to do, even with the strip-feeders.
Keep up the good work guys!

[Bernd Walter]

On Friday, November 3, 2017 at 4:19:02 AM UTC+1, Bernd Walter wrote:

On Sunday, October 29, 2017 at 12:49:29 AM UTC+2, Niels PA1DSP wrote:

Hi Bernd,

Hi Niels,
 I've send you the firmware via direct mail.

Sorry for all the others, but Niels didn't get some or maybe even all of my emails.
Did you receive any of my direct E-Mails?
E.g. you've asked me a few days ago about my location on which I'd replied.
All mails had been accepted by the gmail servers.
This is the log entry for the mail with the firmware:
Nov  3 10:20:32 raven sm-mta[57032]: vA39KQt1057029: to=<n.a.m...@gmail.com>, delay=00:00:05, xdelay=00:00:01, mailer=esmtp, pri=64058, relay=gmail-smtp-in.l.google.com. [IPv6:2a00:1450:400c:c0c::1a], dsn=2.0.0, stat=Sent (OK 1509700832 l79si1350940wmg.191 - gsmtp)

[n.a.m...@gmail.com]

Hi Bernd,

Thanks for the warning - I've found them in my Google spam folder!
I always thought Google had good filters..

Regards,
Niels.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2e7725d0-fa72-472b-b3c9-6e3380a13ccc%40googlegroups.com.

[Bernd Walter]

On Friday, November 3, 2017 at 1:02:20 PM UTC+1, SMdude wrote:

Hmmm, watching this with much interest :D
It seems that at this point in time there is a good cheap supply of these
used feeders about.

Well, you can use them right out of the box without waiting for the protocol,
if you use feeders with a green button per lane.
Prices are only good for dual lane 8mm, 12/16mm are single lane and 2.5 times the
price of a new Yamaha clone.
At least for me it is not worth the price, since I already have a setup to run Yamaha feeders.
You also have to care about the reduction plate to run a 12/16mm siplace feeder with
12mm tapes.
Mark Harries showed that you can remove them for 16mm, in the sense of it is gone forever.
The intended way is screwing it reversed on the feeder, so you don't loose it, but with used
feeders, you don't know what you will get.
The buttons are switched to +5V and hooking up an arduino just worked for me.
No relais are required, but you need to take precautions about ground loops when doing this.
Older ones don't have the button and are often cheaper to get and newer feeders don't have
individual buttons, so analyzing the protocol still makes sense.
That said, the newer feeders, which are tripple lane at 8mm, are much higher priced.
Also most of them have a calibration offset for the pic location, so even with those I have, it
would be better to run them via the bus.
The older feeders can do 4mm only and can be handled by a pneumatic actuator on the head, pushing on a mechanism on the feeder.
Some of the older types also have an electrical connection to actuate either ways.
I guess the majority of us won't use a whole bunch of 2mm pitched tapes, so having
those older 4mm only feeders is still great.

[Bernd Walter]

On Saturday, November 4, 2017 at 6:46:53 AM UTC+1, Bernd Walter wrote:

On Friday, November 3, 2017 at 1:02:20 PM UTC+1, SMdude wrote:

Hmmm, watching this with much interest :D
It seems that at this point in time there is a good cheap supply of these
used feeders about.

Well, you can use them right out of the box without waiting for the protocol,

Just a small update.

Niels did the amazing job of simulating the feeder, not just the microcontroller, but also I/Os and the EEPROM chip.
As already written, the uart is +30V driven with 9600@8n1.
For the test I've used some simple circuit on breadboard.
 I'm an SMD person and had to use what I had as through hole, so values might not be perfect.
CP2102 base UART.
TX via 74HCT04 to invert, feed into ULN2003 via 8k2 into a BC640 to drive the 30V.
RX via 8k2 into ULN2003 and 1k5 pulldown, then from the ULN2003 into the CP2102 with a 3k3 pull up to 5V.

The data consists of:
packetlen command lane [optional data bytes] checksum
The checksum is the byte addition of all the previous bytes.
The answer is in the same format.

The feeder may respond with 2 packets.
It always reacts with a packet acknowledge.
01 e0 e1 if the command was ok.
01 e1 e2 if the command was not ok (timeout, checksum, wrong command, too long, ...)

Some commands send additional data.

02 15 01 18
02 15 02 19
Command 0x15 ask for lane status - the first for lane 1, the other for lane 2.
A response might look like this:
01 e0 e1 02 40 02 44
First 3 bytes acknowledge the request packet.
Then it sends status 0x40 for lane 0x02 with the matching length and checksum bytes.
0x40 means everything is ok.
I've also seen the following:
0x42 if the cover tape won't tension (e.g. no tape inserted or other cover tape failure)
0x43 if the cover tape didn't trigger a retension after a few feeds (e.g. when the cover tape is stuck)
0x44 for feed errors, that is when the feed light gate didn't trigger in time, stuck tape, or such)
Some other error codes might exist, so check for != 0x40.

Command 0x02 is the pre pick command.
E.g. for lane 1:
02 02 01 05
This opens the shutter (the shutter has a timeout, so you have to pick fast).
As long as the shutter is opened, some command restrictions are in place.
It also returns with the same status code as 0x15.

Command 0x03 is the post pick / feed command
E.g. for lane 1:
02 03 01 06
If the shutter is opened it closes the shutter and releases the command restrictions.
Unlike what I wrote about manual operation with the buttons, this command always feeds, no
matter if the shutter is open or not.

That's it for now.
We know several other commands and also the EEPROM read and write commands and some of the EEPROM
values, like step length and feed counters, but I write about it later, when I had the chance to test against
multiple feeders - so far I only connected one real feeder.
That said: It is not required to configure step length via command, since you can also change it via buttons.

This is for the 2x8mm feeders using the 2 motor setup for each lane in a rather early revision.
I assume that other widths and the more modern 3x8mm use the same commands, but I don't have any of them to test.

I also bought some older ones with different mechanical design.
Be carefull, there are a few variants with different connectors, which I don't know and there are even some non electrical.
The older ones can only do 4mm steps.
The ones I have use the same electrical connector as the other one mentions, but that's about it being the same.
They don't have a microcontroller at all and use a step wire for each lane.
They have a single motor for both lanes, which, depending on direction, drives either one of the lanes.
They take almost no current when idle, which is great for power budged, and also run on 30V.
With a 30V pulse on one of the step wires they forward by 4mm.
Don't keep that pulse on for too long or they will do an additional feed as they are level, not edge, triggered.
If the feeder blocks it will take ~200mA and both lanes are in fault condition.
The only way to identify such an error is by measuring the current drawn.
I will start with a breadboard setup for the 30V pulse, but in the final PCB design I will also add current sensors and a power cut.

Keep in mind that most of the feeders are 20+ years old and had been used hard on industrial machines.
I got one, which clearly had been dropped on the floor and has a bend chassis.
If you buy some, be aware that they do need some aftercare or, like the bend one, are even a total fail.
Missing parts are not uncommon, like cover tape reels, spring tensioners or tape width reducers.
You also need reel holders, the reel holders are not part of the feeders.

[Cri S]

Great to hear it, specially that you test older dual lane feeders (24€ each).
Do you have found out the way to read and set the feeder id and part id.
Not really important, as replacing the connector with db9 allows to
put eeprom id circuit
into that connector, (0V, 30V, 15V ( as gnd, +-15V allows to connect
it safely to rs232 circuit without damage) rs232 rx/tx . This are 5
wires , 4 free. In reality one is probably used for enabling TX
(transistor or optocoupler) remaining 3 pins free.
Probably it is worth adding this eeprom as it allows encoding
part/package info into feeder.
What is needed
xyz dimension
vision-id , feeder-id, part-id.
If binary 4+16+4=24 byte is needed, having 15 byte for part-id and 1
byte for lightning.
If need compressing, 14 byte can be omitted, this is then 10 byte.
On the other side, needing 10 byte AT24C16D can contain over 1000 feeders..

> --
> You received this message because you are subscribed to the Google Groups
> "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to openpnp+u...@googlegroups.com.

> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/433c0369-1a11-45b9-a75d-e210f532941e%40googlegroups.com.

[Bernd Walter]

On Saturday, November 11, 2017 at 5:02:38 PM UTC+1, Cri S wrote:

Great to hear it, specially that you test older dual lane feeders (24€ each).
Do you have found out the way to read and set the feeder id and part id.

It is more complicated.
The EEPROM holds 32 bytes - 16 per lane.
You can read the EEPROM with command 0x17  and all 16 bytes for the selected lane are returned.
Command 0x19 writes either all 16 bytes, or just 2 specific bytes.
I understand it that those 2 bytes are to be updated more regular by the machine and justified a separate subcommand.

This is what my test feeders returns:
lane 1:
0a 53 33 ef 01 24 11 01 c6 8a b6 d5 03 b3 00 00
lane 2:
15 07 0b 87 00 18 00 3c 9b 6f e7 00 02 02 00 00

low byte first.
Pos 0x2/3 (0xef33 and 0x87eb) are the feed counts for the lanes.
The next byte 0x4 is the step amount 0x00 is 2mm and 0x01 4mm.
Pos 0x6/7 are the positions with the extra subcommand

I have no idea about the remaining values yet, but Niels did more research with
the emulator and has an idea which values might be used by the feeder itself.
What I want to do is waiting until I've hooked up all the 8 feeders and see how
the values differ.
The must be some pick calibration data in there, but this is pure info for the PnP machine itself and unused by the feeder.
There are also more positions touched by the feeder, but more research is needed.
It looks like the last 2 bytes are unused and can be repurposed, but keep in mind that my feeders are very early ones and things can be different with others.

The older feeders are way different.
They are simple transistor/relais based state machines.
No microcontroller, no EEPROM.
The motor rotates left or right until the lane stop position microswich is triggered.
A complex cam system moves drag pins to forward the tape.
Another switch acts as a feed button for manual and machine operation.
Very old machines have a pneumatic actuator for mechanical feeders.
https://youtu.be/8geFoSQASiA
The feeders used in the video are the same type electrical as I used, but you see the pneumatic
actuator, which would also be used to advance non electrical feeders.
On those electrical feeders they just trigger a micro switch and the pig tail connector is used for power only.
Newer machines uses the pig tail to send a feed pulse.
The PCB on those feeders can be replaced quite easily - nice rather big rectangular format with one holding screw.
Not a long small strip PCB as in the newer ones.
Also the connectors are easy and cheap to source.
All 4 switches and the motor uses Micromatch connectors.
The pigtail is connected with screw terminals.
You just need an H-bridge, some GPIO and whatever kind of bus interface you'd like.
The downside is that they are much older and can only do 4mm feeds, unless you write your own feeder class with double pick feature.
But I'm not sure the mechanic is accurate enough for 0402 parts anyway.

[Cri S]

> It is more complicated.
> The EEPROM holds 32 bytes - 16 per lane.
> You can read the EEPROM with command 0x17 and all 16 bytes for the
> selected lane are returned.
> Command 0x19 writes either all 16 bytes, or just 2 specific bytes.
> I understand it that those 2 bytes are to be updated more regular by the
> machine and justified a separate subcommand.
>

This is probably the feed counter, and probably this counter is shadowed to more
eeprom location in order to avoid eeprom wareout, and usually in this
case there is
a countdown counter or stored as binary complement (~ operator) as
this double the possible eeprom cycles. EEprom if firmware supports
that.

I know that there is a separate overall feed counter, but it is
possible that if this
2byte counter overflow, annother 2byte counter is increased and the difference
of current feed count and overall feed count is only software based.
This overflow could be automatic inside feeder on handled by software (pc).

> This is what my test feeders returns:
> lane 1:
> 0a 53 33 ef 01 24 11 01 c6 8a b6 d5 03 b3 00 00
> lane 2:
> 15 07 0b 87 00 18 00 3c 9b 6f e7 00 02 02 00 00

cntHi cntLo sp fdr-id ^--part-id-^ x/yoffset z??offset??
-y offset = 12 bit 40,96mm max
z offset = 16 bit or maybe used for tray ?
>
just a guess

[Bernd Walter]

On Sunday, November 12, 2017 at 2:39:22 PM UTC+1, Cri S wrote:

> It is more complicated.
> The EEPROM holds 32 bytes - 16 per lane.
> You can read the EEPROM with command 0x17  and all 16 bytes for the
> selected lane are returned.
> Command 0x19 writes either all 16 bytes, or just 2 specific bytes.
> I understand it that those 2 bytes are to be updated more regular by the
> machine and justified a separate subcommand.
>
This is probably the feed counter, and probably this counter is shadowed to more
eeprom location in order to avoid eeprom wareout, and usually in this
case there is
a countdown counter or stored as binary complement (~ operator) as
this double the possible eeprom cycles. EEprom if firmware supports
that.

No - the EEPROM is a special beast.
It is a Q24C44, which is a RAM with EEPROM backing.
It is my understanding, that it always writes the full 32 bytes.
There must be some kind of power failure support for the MCU, which is running against a GPIO we don't know yet.
Otherwise a feed counter would easily kill the chip, which only has 1m write cycles.
 

I know that there is a separate overall feed counter, but it is
possible that if this
2byte counter overflow, annother 2byte counter is increased and the difference
of current feed count and overall feed count is only software based.
This overflow could be automatic inside feeder on handled by software (pc).

So far I just know that those 2 bytes I mentioned are the only ones updated during feeds.
And those won't match with the special 2 bytes.
I also couldn't see a change on errors.
About the theory for a 32bit counter, we should see when we analyze the code a bit further.
I got the feeder counter from real hardware and only had a byte rollover during tests.
 

> This is what my test feeders returns:
> lane 1:
> 0a 53 33 ef   01 24 11   01 c6 8a b6   d5 03 b3  00 00
> lane 2:
> 15 07 0b 87 00 18 00   3c 9b 6f e7    00 02 02  00 00
     cntHi cntLo sp  fdr-id   ^--part-id-^      x/yoffset   z??offset??
-y offset = 12 bit  40,96mm max
 z offset = 16 bit or  maybe used for tray ?

I did notice some other bytes changed over time, but reasons are unknown.
Calibration data shouldn't change, so those bytes are unlikely to be calibration related.
Also Niels spotted locations used in firmware.
He noticed that some locations are written during start.
As said: more research is needed and it is too early to speculate.
Also comparing with the other feeders might reveal a pattern not obvious by just one feeder.
I personally hope that the Y offset is from feeder center, so the left lane always has a negative
offset and the right always a positive offset, that way we may get a hint about those values as
the ideal mm offset can be measured.
Otherwise identifying the pick location offsets would be 100% guess work.
So far we just know the 16bit counter and the feed length fields for sure.

[Cri S]

Do you have access to real siplace including software? If yes, there is a VB feeder admin tool that know a lot about feeder and use the oid interface (free but require NDA signing).

If you can confirm it can be used, I check for getting the tool.

Probably pin7 is used for hw store.

And maybe the last 2 bytes and the upper byte of feed length are used during update to recover from power loss during write.

This is how I probably would do it with that hw to have error proof nvm.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b3f3f79f-bda0-47d8-a18d-3c5e99f64d7e%40googlegroups.com.

[Cri S]

The 2 lane have  a fiducial that is used for feeder position as I know.

Il domenica 12 novembre 2017, Bernd Walter <be...@bwct.de> ha scritto:

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b3f3f79f-bda0-47d8-a18d-3c5e99f64d7e%40googlegroups.com.

[Bernd Walter]

On Sunday, November 12, 2017 at 7:30:43 PM UTC+1, Cri S wrote:

Do you have access to real siplace including software? If yes, there is a VB feeder admin tool that know a lot about feeder and use the oid interface (free but require NDA signing).

If you can confirm it can be used, I check for getting the tool.

No - I don't have access to a machine, just the 2 types of feeders.
00141091 the newer controller based ones
00141105/13 and 00141107-01 for the older ones without controller.

Probably pin7 is used for hw store.

There is no extra pin.
the connector has 7 pins, but the cable used is a 4-wire only.
Ground, +30V, RX and TX for the newer.
Ground, +30V, feed left, feed right for the older
One feed pin matches with the RX of the newer, the other feed uses a pin unused on the newer.
But I just did a quick test, because I removed the connectors already.

And maybe the last 2 bytes and the upper byte of feed length are used during update to recover from power loss during write.

This is how I probably would do it with that hw to have error proof nvm.

I'm pretty sure they have a lower voltage on the 30V.
They should have enough time.
On the newer PCB with Marks feeders there is a MAX30x part - couldn't read the last digit, but it is a monitoring chip.
 

[Bernd Walter]

On Sunday, November 12, 2017 at 7:32:41 PM UTC+1, Cri S wrote:

The 2 lane have  a fiducial that is used for feeder position as I know.

This could be true for the pulse driven, they have a hole in the masking plate.
I don't think this could work with the controller based.

I've attached a picture of both feeders side by side.

The controller based have 2 notches and depending on the part you use different pick locations.
I've also attached a picture showing a label describing this.
But I don't see how you can calibrate the feed stop position mechanically and the software trusts a mechanical end stop.
Between the end stop and the sprocket wheel is a gear train, which can be off.

[Cri S]

https://www.google.it/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwjg5cb2i7rXAhXiHpoKHZjGCsUQFggmMAA&url=https%3A%2F%2Fwww.siplace.com%2Faddmindms%2Fdownload.aspx%3Fdomid%3D10%26d_id%3Dd90a721d-9053-4b80-bd3f-1e6ae37b13ac%26fdl%3D1&usg=AOvVaw01y1zJClOeYIUiB7MGqzuq

Maybe that could help.

> --
> You received this message because you are subscribed to the Google Groups
> "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to openpnp+u...@googlegroups.com.

> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/dbc537d5-9bde-4645-a765-937da25fc6b5%40googlegroups.com.

[Bernd Walter]

On Monday, November 13, 2017 at 12:42:12 AM UTC+1, Cri S wrote:

https://www.google.it/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwjg5cb2i7rXAhXiHpoKHZjGCsUQFggmMAA&url=https%3A%2F%2Fwww.siplace.com%2Faddmindms%2Fdownload.aspx%3Fdomid%3D10%26d_id%3Dd90a721d-9053-4b80-bd3f-1e6ae37b13ac%26fdl%3D1&usg=AOvVaw01y1zJClOeYIUiB7MGqzuq

Maybe that could help.

I know this document, but this is for X-Feeders.
What I use are called S-Feeders.
I don't know if they have anything in common with the S-feeders, but they mount and interconnect completely differently.
Since they are mechanical incompatible I would be surprised if they didn't redesign the whole communication to be up to modern standards.
As far as I know you can get a S-feeder bank for X-Machines to keep old feeders, but that's all about it.

[Cri S]

Yes,  know that, but as Siemens feeders was bought from another company that patented it (the patent mention just the 16 byte eeprom) and xfeeder was coming out at patent expiration date the probably is high that there share the same base.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cc833b11-e8d5-41a1-badd-395ac750b4d4%40googlegroups.com.

[Bernd Walter]

On Monday, November 13, 2017 at 12:18:50 PM UTC+1, Cri S wrote:

Yes,  know that, but as Siemens feeders was bought from another company that patented it (the patent mention just the 16 byte eeprom) and xfeeder was coming out at patent expiration date the probably is high that there share the same base.

I'm not aware of that patent - I saw a few when searching for any kind of documentation, but didn't notice anything interesting.
Would be curious to read it.
However - your document shows informations about X-feeders, which can't possibly fit into the 16 bytes, so it is extended at least.

[phon...@gmail.com]

Just for info: 

The datamatrix code (7x7) format is for single lane feeder:

1PXXXXX+S+1SYYYYY

and for more lane feeder 

1PXXXXX+S+1SYYYYY+F1   first lane

1PXXXXX+S+1SYYYYY+F2   second lane

XXX is Part-ID and YYY is feeder ID of any length 

[Bill Ruckman]

Hello Niels,

I am working on a controller for Siplace Feeders to work with OpenPnP.  Would you be willing to share what you have learned about the protocol and EEPROM layout?

Thank you.

Best regards,

--Bill Ruckman

On Friday, October 27, 2017 at 1:22:44 PM UTC-7, Niels wrote:

Hi Bernd,

Can you send me the EPROM binary? I will try to recover the protocol, if you're interested.

Regards,

Niels.

On Fri, Oct 27, 2017 at 9:08 PM, Bernd Walter <be...@bwct.de> wrote:

On Friday, October 27, 2017 at 12:07:54 PM UTC+2, Marek T. wrote:

Do you mean there is 0-30V level on the data bus?? And txd only?

30V signaling is very plausible.
I've measured a 15k resistor between connector and opto, which translates to 2mA.
Also UART is very plausible, since the 80C32 has HW support for that and it would be silly to use something else.
Later feeder of the S-series have some kind of bidirectional transfer.
In my model only 4 wires are used - 2 power, plus 2 for the opto, but the connector to the machine has 7 pins.
I doubt it is encrypted, but since I don't have access to a machine all I could do is using the firmware binary.
I'm not going to do this.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bf8a88d8-5b9e-4bf7-870a-1b4a6b490d82%40googlegroups.com.

[Bernd Walter]

On Wed, Jan 22, 2020 at 12:52:20PM -0800, Bill Ruckman wrote:
> Hello Niels,
>
> I am working on a controller for Siplace Feeders to work with OpenPnP.
> Would you be willing to share what you have learned about the protocol and
> EEPROM layout?

We havn't found out everything, some commands were not obvious what they do.
But we got enough to use the feeders.
The eeprom is tricky - we don't know what the contents are and have no way
to find out, because most of it is parsed by the machine.
My assumption is that the contain calibration values for the pick location.
You can read the 16 bytes content for lane 1 with hex: 02 17 01 1a
There is a feed counter in bytes 12 (low) and IIRC byte 11.
For lane 2 that is: 02 17 02 1b

I think the value for 2mm and 4mm feed was also obvious, but you can
configure it via buttons.

The most important commands are:
02 02 01 05 - lane 1 pre pick / opens shutter
01 e0 e1 02 40 01 43 - 0x40 = ok, 0x42 nicht ok, 0x44 cover tape feed error
02 02 02 06 - lane 2 pre pick / opens shutter
01 e0 e1 02 42 02 46

The 01 lines are the response from the feeder.
The last byte is always the checksum - literally an addition with overflow.
The 5th byte is the important one, because it says if the feeder is ready
or in an error state.

You can cancel a feed operation with:
02 03 01 06 - no feed operation???
This just closes the shutter.

Or close the shutter with a feed operation using:
02 03 02 07 - feed operation

Be aware that the shutter has a timeout and automatically closes.
I'm running my OpenPnP with a local patch to position the nozzle above the
pick position before doing the prepick feeder command.

I havn't done anything more with this because of other projects.
My machine is running with pulse driven siplace feeders.
Hopefully after I'll find more time soon to complete it.

I had dropped everything relevant we've found on the list back then.
We do know the the GPIO connections as well, but I have to check up
my documentation for that.

>
> Thank you.
> Best regards,
> --Bill Ruckman
>
> On Friday, October 27, 2017 at 1:22:44 PM UTC-7, Niels wrote:
> >
> > Hi Bernd,
> >
> > Can you send me the EPROM binary? I will try to recover the protocol, if
> > you're interested.
> >
> > Regards,
> > Niels.
> >

> > On Fri, Oct 27, 2017 at 9:08 PM, Bernd Walter <be...@bwct.de <javascript:>

> > > wrote:
> >
> >>
> >>
> >> On Friday, October 27, 2017 at 12:07:54 PM UTC+2, Marek T. wrote:
> >>>
> >>> Do you mean there is 0-30V level on the data bus?? And txd only?
> >>
> >>
> >> 30V signaling is very plausible.
> >> I've measured a 15k resistor between connector and opto, which translates
> >> to 2mA.
> >> Also UART is very plausible, since the 80C32 has HW support for that and
> >> it would be silly to use something else.
> >> Later feeder of the S-series have some kind of bidirectional transfer.
> >> In my model only 4 wires are used - 2 power, plus 2 for the opto, but the
> >> connector to the machine has 7 pins.
> >> I doubt it is encrypted, but since I don't have access to a machine all I
> >> could do is using the firmware binary.
> >> I'm not going to do this.
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "OpenPnP" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an

> >> email to ope...@googlegroups.com <javascript:>.

> >> To post to this group, send email to ope...@googlegroups.com

> >> <javascript:>.

> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/openpnp/bf8a88d8-5b9e-4bf7-870a-1b4a6b490d82%40googlegroups.com

> >> <https://groups.google.com/d/msgid/openpnp/bf8a88d8-5b9e-4bf7-870a-1b4a6b490d82%40googlegroups.com?utm_medium=email&utm_source=footer>
> >> .

> >>
> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
>

> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/23b726d0-e9a9-4e52-bb53-0f3f4dd2c886%40googlegroups.com.


--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

[Bill Ruckman]

Thank you Bernd!  So can you write to the EEPROM to change from 2mm to 4mm, or is that only through the buttons?

> To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[Bernd Walter]

On Wed, Jan 22, 2020 at 02:02:38PM -0800, Bill Ruckman wrote:
> Thank you Bernd! So can you write to the EEPROM to change from 2mm to 4mm,
> or is that only through the buttons?

I don't think we've found an eeprom write routine, but I'm not sure.
There likely is one.
I may investigate it later after I've implemented the uart firmware part
for my PCBs, because my feeders have old style buttons and quite a few
are mechanically broken.
Doing that via buttons is super easy though and you do want functional
buttons to insert a tape.

> > an email to ope...@googlegroups.com <javascript:>.

> > > To view this discussion on the web visit

> > https://groups.google.com/d/msgid/openpnp/23b726d0-e9a9-4e52-bb53-0f3f4dd2c886%40googlegroups.com.
> >
> >
> >
> > --
> > B.Walter <be...@bwct.de <javascript:>> http://www.bwct.de

> > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> >
>

> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a8bb64a2-4d83-40fd-b3ac-09f188d35cd6%40googlegroups.com.

[Bill Ruckman]

I've been able to communicate with the feeders using a arduino board thanks to the information you previously posted.  I wasn't able to do anything with the EEPROM though.  Those commands didn't return anything.  Could be that I'm doing something wrong though.  Here are some examples:

Sending: 02 01 01 04 

Receive: 01 E0 E1         ⸮

Receive: 23 81 02 04 32 30 2E 30 35 2E 39 38 20 20 20 20 6D 69 74 20 46 53 5A 20 54 65 73 74 72 6F 75 74 69 6E 65 00 E1         ⸮..20.05.98    mit FSZ Testroutine.

Sending: 02 02 01 05 

Receive: 01 E0 E1         ⸮

Receive: 02 42 01 45         B.

Sending: 02 03 01 06 

Receive: 01 E0 E1         ⸮

Sending: 02 03 02 07 

Sending: 02 15 02 19 

Receive: 01 E0 E1         ⸮

Receive: 02 40 02 44         @.

Sending: 02 15 02 19 

Receive: 01 E0 E1         ⸮

Receive: 02 42 02 46         B.

Sending: 02 17 01 1A 

Receive: 01 E0 E1         ⸮

Sending: 02 17 02 1B 

Receive: 01 E0 E1         ⸮

> To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[Cosyne Wave]

I have a working Siplace machine here. 

No, it is not possible to change the pitch 2mm or 4mm through controller for regular (Shultz) feeders. Standard procedure for feeder changing pitch only with integrated buttons, usually done when loading components into feeder. 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/20200122221642.GD36258%40cicely7.cicely.de.

[Bernd Walter]

On Wed, Jan 22, 2020 at 05:00:15PM -0800, Bill Ruckman wrote:
> I've been able to communicate with the feeders using a arduino board thanks
> to the information you previously posted. I wasn't able to do anything
> with the EEPROM though. Those commands didn't return anything. Could be
> that I'm doing something wrong though. Here are some examples:
>
> Sending: 02 01 01 04

02 17 01 1a
and
02 17 02 1b

Sorry if I mixed something up.

> Receive: 01 E0 E1 ???

> Receive: 23 81 02 04 32 30 2E 30 35 2E 39 38 20 20 20 20 6D 69 74 20 46 53

> 5A 20 54 65 73 74 72 6F 75 74 69 6E 65 00 E1 ???..20.05.98 mit FSZ

> Testroutine.
> Sending: 02 02 01 05

> Receive: 01 E0 E1 ???

> Receive: 02 42 01 45 B.
> Sending: 02 03 01 06

> Receive: 01 E0 E1 ???

> Sending: 02 03 02 07
> Sending: 02 15 02 19

> Receive: 01 E0 E1 ???

> Receive: 02 40 02 44 @.
> Sending: 02 15 02 19

> Receive: 01 E0 E1 ???

> Receive: 02 42 02 46 B.
> Sending: 02 17 01 1A

> Receive: 01 E0 E1 ???

> Sending: 02 17 02 1B

> Receive: 01 E0 E1 ???

> > an email to ope...@googlegroups.com <javascript:>.

> > > To view this discussion on the web visit

> > https://groups.google.com/d/msgid/openpnp/a8bb64a2-4d83-40fd-b3ac-09f188d35cd6%40googlegroups.com.

> >
> >
> >
> > --
> > B.Walter <be...@bwct.de <javascript:>> http://www.bwct.de
> > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b9d48824-fd22-49bd-a479-d8e02d624cfb%40googlegroups.com.

[Bill Ruckman]

Thank you @Cosyne Wave.  Is there any information about the loaded part that is stored in the feeder EEPROM?

> To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a8bb64a2-4d83-40fd-b3ac-09f188d35cd6%40googlegroups.com.


--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[Cosyne Wave]

No, in S (Shultz) feeders and older versions there is no information about the loaded part into the feeder EEPROM.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e39ded0e-44b7-4ceb-a9cb-374acf660aa1%40googlegroups.com.

[Mike M.]

Hello Cosyne,

With ref. to "No, it is not possible to change the pitch 2mm or 4mm through controller for regular (Shultz) feeders. Standard procedure for feeder changing pitch only with integrated buttons"

Can you please explain the sequance with buttons needed to change from 2 or 4mm feeding ?

Thanks

Mike

> To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a8bb64a2-4d83-40fd-b3ac-09f188d35cd6%40googlegroups.com.


--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[Cosyne Wave]

>Can you please explain the sequance with buttons needed to change from 2 or 4mm feeding ?

Of course, Mike

I think you are interested about the sequence for 2X8mm S feeders. For 12/16, 3X8, 24/32 etc, it is obvious because of the incorporated pitch display  

The pitch changing shall be made with the reel loaded, that means the cover-tape tensioner must be tensioned (pressed).all the time during changing.

Then press and hold the green button and when the cover window is released (2 sec)  press brieffly one time  for 2mm pitch or two times for 4mm pitch on yellow button, than release the green button. The feeder will signal the selected pitch by one LED flash for 2mm pitch or two flashes for 4mm pitch.   

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bb3abcf8-0ca6-49c7-a458-867c7887ad19%40googlegroups.com.

[Mike M.]

Great -Thanks Cosyne ! 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bb3abcf8-0ca6-49c7-a458-867c7887ad19%40googlegroups.com.

[Bill Ruckman]

@Cosyne

I am able to read the feed count from the EEPROM.  Is there a way to reset the count when a new reel of components is loaded?

Is there any other status reported to the machine?  For example, I see one counter that increments on power cycles.

I appreciate you insight into how these feeders work in a real system!

Best regards,

--Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bb3abcf8-0ca6-49c7-a458-867c7887ad19%40googlegroups.com.

[Bernd Walter]

On Sat, Jan 25, 2020 at 09:40:57AM -0800, Bill Ruckman wrote:
> @Cosyne
>
> I am able to read the feed count from the EEPROM. Is there a way to reset
> the count when a new reel of components is loaded?
> Is there any other status reported to the machine? For example, I see one
> counter that increments on power cycles.
> I appreciate you insight into how these feeders work in a real system!

Well - the command byte routine is very easy to analyze.

First byte is always 0x02, second the command, 3rd the lane.
The lane may be ignored by commands, but is always part of the
request.

We know for sure that it uses the following command bytes:
0x10
0x03 - close shutter, with or without feed
0x11
0x12 - purpose unknown, but blocked when shutter is open
0x15 - ask for lane ready status
0x16
0x17 - read eeprom for lane
0x18
0x19 - uses lane number, otherwise unknown
0x1c
0x1d
0x02 - open shutter / prepick
0x1e
0x01 - read firware info
02 01 02 05
01 e0 e1 23 81 02 03 31 32 2e 31 32 2e 39 34 20 20 20 20 6d 69 74 20 46 53 5a 20 54 65 73 74 72 6f 75 74 69 6e 65 00 db
# 1 2 . 1 2 . 9 4 m i t F S Z T e s t r o u t i n e
The 02 03 can be firmware revision 2.3, with which the EPROM was labeled with

0x1f - delivers unknown bytes: 01 e0 e1

Especially Nick went a bit deeper into the code, but the command parser
is just an interrupt routine, which sets flags.
We didn't bother to find out more details, since we have had what we
absolutely needed and the rest seemed very time consuming.

>
> Best regards,
> --Bill
>
>
> On Friday, January 24, 2020 at 3:27:49 PM UTC-8, Cosyne Wave wrote:
> >
> >
> > >Can you please explain the sequance with buttons needed to change from 2
> > or 4mm feeding ?
> >
> > Of course, Mike
> > I think you are interested about the sequence for 2X8mm S feeders. For
> > 12/16, 3X8, 24/32 etc, it is obvious because of the incorporated pitch
> > display
> >
> > The pitch changing shall be made with the reel loaded, that means the
> > cover-tape tensioner must be tensioned (pressed).all the time during
> > changing.
> > Then press and hold the green button and when the cover window is released
> > (2 sec) press brieffly one time for 2mm pitch or two times for 4mm pitch
> > on yellow button, than release the green button. The feeder will signal the
> > selected pitch by one LED flash for 2mm pitch or two flashes for 4mm
> > pitch.
> >
> >
> >
> >

> > On Fri, Jan 24, 2020 at 6:04 PM Mike M. <mike...@gmail.com <javascript:>>

> >> https://groups.google.com/d/msgid/openpnp/bb3abcf8-0ca6-49c7-a458-867c7887ad19%40googlegroups.com
> >> <https://groups.google.com/d/msgid/openpnp/bb3abcf8-0ca6-49c7-a458-867c7887ad19%40googlegroups.com?utm_medium=email&utm_source=footer>

> >> .
> >>
> >
>
> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/953a2d8e-0b1f-4bc4-97b5-2728b7a8b100%40googlegroups.com.

[Bernd Walter]

Btw.:
It might be that one of the above unknown commands resets the counter.
I just never checked for that.
Unlike Nick I could test with a real feeder.
We have had no IOs and EEPROM in the simulator.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/20200125211214.GC72278%40cicely7.cicely.de.

[Bill Ruckman]

I can reset it through the eeprom.  I was wondering if there was some magic combination of button presses that might do it.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/953a2d8e-0b1f-4bc4-97b5-2728b7a8b100%40googlegroups.com.
>
>
> --
> B.Walter <be...@bwct.de> http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
>
> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[Bill Ruckman]

0x01 - read firware info
       02 01 02 05
       01 e0 e1 23 81 02 03 31 32 2e 31 32 2e 39 34 20 20 20 20 6d 69 74 20 46 53 5a 20 54 65 73 74 72 6f 75 74 69 6e 65 00 db
                #           1  2  .  1  2  .  9  4              m  i  t     F  S  Z     T  e  s  t  r  o  u  t  i  n  e
       The 02 03 can be firmware revision 2.3, with which the EPROM was labeled with

I think you're right about the firmware version.  I have version 2.4 and I see 02 04 in those bytes.  The rest of the string is the same except for the date.

  81 02 04 32 30 2E 30 35 2E 39 38 20 20 20 20 6D 69 74 20 46 53 5A 20 54 65 73 74 72 6F 75 74 69 6E 65 00

[Bill Ruckman]

I have decoded all of the NVRAM for the 2x8mm feeders now.

Each lane has 16 bytes of NVRAM.  The following is for each lane, unless otherwise noted.

Bytes 0 and 1 are ID bytes.  They are not used internally by the firmware.  For my feeders, the ID in lane 1 matched the last 5 digits printed on the label and encoded in the 2d barcode.  I wasn't able to match the value in lane 2 with anything printed on the feeders.

Bytes 2, 3, and 5 are a 24 bit feed count.  It is incremented on every feed operation.  Byte 2 is the low byte, ad 5 is high.

Byte 4 is the part pitch. 0 = 2mm, 1 = 4mm

Byte 6 is the mode.  For normal operation it is 31h in lane 1, 0 in lane 2.  Other values may be read during test mode.

Byte 7 is enable.  Bit 0 = 1 to enable.  If bit 6 = 1 and bit 0 = 1, test mode is entered on power up.

Byte 8 and the lower nibble of byte 12 form a 12 bit counter of error 42h picks.

Byte 9 and the upper nibble of byte 12 form a 12 bit counter of error 43h picks.

Byte 10 and the lower nibble of byte 13 form a 12 bit counter of feed errors (44h).

Byte 11 and the upper nibble of byte 13 form a 12 bit counter of resets (power cycles).

Bytes 14 and 15 are not used and are always zero in the feeders I have looked at.

[Cosyne Wave]

Hello Bill,

I missed your request.

I think I am able to shed some light into this.

Into S feeders NVRAM there are stored informations about:

- date of manufacture

- firmware date and version, something like:  1.3 (1997-04-25)  

- total number of cycles for each line 

none of them can be reset with commands, AFAIK.

there is no information about ajustement

no information about the component loaded etc. It is not what is known as an "intelligent feeder" stricto sensu.

. 

I can provide on request tracing for different feeder commands.

[Bill Ruckman]

Hi Cosyne,

I have it pretty well figured out now.  The driver is already integrated into OpenPnP.  It probably has more functionality than what was available on the original machine.  The GUI is able to read and clear counts, as well as set the pitch.

https://github.com/openpnp/openpnp/wiki/SchultzFeeder-and-SlotSchultzFeeder 

Best regards,

--Bill

 

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e73fee28-ecdf-4c58-8470-fd2fc2f3a87d%40googlegroups.com.

[Wladimir Nickel]

Hi.

Want to Thank You all for this.

I've built a testing device for my feeders using your work.

[Bill Ruckman]

Very nice!

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ecb5d24c-3554-4269-a8a7-5697d7a09effo%40googlegroups.com.

[Mike Menci]

Great Wladimir is there a description - can be in German somwhere on web ?

Mike

[Wladimir Nickel]

Hi Mike,

I will put it on my GitHub account within view days (thanks to Jason, I 've got one ;-) ).

[Mike Menci]

Great Wladimir - let us know when it is ready.

Thanks

Mike

[Wladimir Nickel]

Sorry, no motivation to bother with init, add, commit etc...

So here are my files.

- Changed config.h to support just one feeder instead of 20.

- Changed Feeder.cpp to support Arduino Nano (not Every). I used the hardware UART for programming and debugging in the .ino sketch and SoftSerial for receiving data from feeder in Feeder.cpp. Transmitting is still done by the original driver of bilsef. This is because of inverted signal.

- Level shifting like in the schematic of bilsef, but used just one channel.

- Keyboard is this part: https://www.tme.eu/de/en/details/kb304-pnw/plasitc-keypads/accord/ak-304-n-wwb/

- Display is a standard 16x2 character LCD.

- Added one 7805 for the Arduino Nano.

That's it.

[Mike Menci]

Great Thanks Wladimir

[Simon Ruetz]

Hello,

I'm currently trying to control a 2x8mm feeder using a Uart coneverter and a Siplace feeder controller (e.g. with Hex Code 02 02 01 05).
Unfortunately I receive 01 e1 e2 (command was not okay) every time.

I have already tested different feeders.
Does anyone have an idea what it could be?

be...@bwct.de schrieb am Samstag, 11. November 2017 um 07:42:31 UTC+1:

The feeder may respond with 2 packets.

It always reacts with a packet acknowledge.
01 e0 e1 if the command was ok.
01 e1 e2 if the command was not ok (timeout, checksum, wrong command, too long, ...)

[Mike Menci]

Hi Simon - Are you using this as controller ? If so - which board Every or Nano ? 

https://github.com/openpnp/openpnp/wiki/SchultzFeeder-and-SlotSchultzFeeder

[Simon Ruetz]

Hello Mike,

thanks for your answer.

I don't use a Arduino, only the the driver circuit for UART. 

I plan to build a Siplace feeder test station with a camera for calibration. At least I have the original software and can't control the feeder with it. 

So I then only tried using the terminal and hex code without success. I could try it with the Arduino and OpenPnP, but I don't think anything will change.

[Mike Menci]

So you are running this code from  Wladimir Nickel (above enclosed- SchultzFeederTester.zip) and UART ?   
When you say : "  I have the original software" is that from Siemens for Siemens calibration Jig ? 

Please clarify

Mike

[Simon Ruetz]

I have the software for the Siplace S-Feeder Checking Device 03071323-01.

Yes, it's for the calibration jig but you can also control S-feeders like 2x8mm, 3x8mm and so on.

Controlling the feeder and the vision works independently.

It seems to use similar commands as Bernd Walter wrote above.

The software says that there is a connection problem to the feeder, but the feeder is also responding the code 01 E1 E2.

I'm getting back the same code when I'm sending the hex code (e.g. pre pick-up command from Bernd Walter "02 02 01 05") manually with a terminal (9600 bauds).

So I don't know where my mistake is.

[Mike Menci]

This video might help you out: https://www.youtube.com/watch?v=_snAjJtib24
good luck - keep us posted how it will go.. 

Thanks

Mike

[Mike Menci]

Min 18.30 of the video.....

[Simon Ruetz]

Thanks for the video. 

I think I saw this a long time ago, but I can't remember of the part of disassembling the code.

I checked the Hex code for the "Single Step (F5)" of the original software tool and the hex code 02 02 01 05 in this thread. And there are exactly the same.

I also checked the UART levels and they should be ok.

So I don`t understand what I'm doing wrong?

[Mike Menci]

Hi Simon, 

I am not familiar with hex … 

I would try to contact the above mentioned video creator ! 

Rgds & good luck 

Mike 

Sent from my iPhone

On 12 Mar 2024, at 17.48, Simon Ruetz <simonr...@gmail.com> wrote:

Thanks for the video. 

I think I saw this a long time ago, but I can't remember of the part of disassembling the code.

I checked the Hex code for the "Single Step (F5)" of the original software tool and the hex code 02 02 01 05 in this thread. And there are exactly the same.

I also checked the UART levels and they should be ok.

So I don`t understand what I'm doing wrong?

<UART.png>

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1b9933d6-8a84-4240-8937-e948b71aa6dbn%40googlegroups.com.

<UART.png>

[Simon Ruetz]

Thanks Milke,

there are no contact details on his website and most of the comments on YouTube are unanswered. So I have little hope.

Maybe somebody here in the thread is able to meassure the communication (of a single step left) of his SchulzFeederController. That would help.

[Mike Menci]

Yes I saw it now - latest video is 2 year old.....    I hope someone here in OpenPnP group can help! 

Cheers

Mike

[Simon Ruetz]

I found the issue. The UART-TX signal must be actively low instead of high. Usually this is wrong. But that's how it works.