Neoden 4 autofeeders

[Dylan Dodge]

I am in the process of adding PnP functionality to a multi-tool printer design when I came across the Neoden 4 feeders. These feeders work perfectly within my space constraints, but I have been having trouble gaining functionality of one. Has anyone been able to hack one yet?

[Jason von Nieda]

I posted a teardown of one a while back: https://imgur.com/a/osEGC

Near the bottom, there is an image where I identified most of the components.

I know that it's CAN bus, but that's about all. Since I don't have a Neoden 4 I was never able to hook it up and get it working so I could sniff the messages.

Jason

On Wed, Jul 24, 2019 at 12:52 PM Dylan Dodge <dcd...@ucsb.edu> wrote:

I am in the process of adding PnP functionality to a multi-tool printer design when I came across the Neoden 4 feeders. These feeders work perfectly within my space constraints, but I have been having trouble gaining functionality of one. Has anyone been able to hack one yet?

--
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/ebc42f59-ca8f-4995-9444-f10923ad3f59%40googlegroups.com.

[Dylan Dodge]

Hi Jason, 

I had purchased one to do a tear down as well as hopefully hack the CAN Bus. Unfortunately, I have not been able to sniff the bus. It seems that the components are in a hibernation mode until a command is sent to the component. I have had no luck in waking up the component, but have noticed that if a high signal is on the bus there is an LED that lights up which tells me that it is at least reading the bus. I don't really know where to go from here to gain access to the motor because even if I wake up the component to get the ID; how will I know what message to send it so that it will move the motor. It seems this may be a dead end which is unfortunate because this part would work perfectly in my application. 

Dylan

On Wednesday, July 24, 2019 at 11:07:34 AM UTC-7, Jason von Nieda wrote:

I posted a teardown of one a while back: https://imgur.com/a/osEGC

Near the bottom, there is an image where I identified most of the components.

I know that it's CAN bus, but that's about all. Since I don't have a Neoden 4 I was never able to hook it up and get it working so I could sniff the messages.

Jason

On Wed, Jul 24, 2019 at 12:52 PM Dylan Dodge <dcd...@ucsb.edu> wrote:

I am in the process of adding PnP functionality to a multi-tool printer design when I came across the Neoden 4 feeders. These feeders work perfectly within my space constraints, but I have been having trouble gaining functionality of one. Has anyone been able to hack one yet?

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

[Jason von Nieda]

Someone in this thread ( https://www.eevblog.com/forum/manufacture/neoden-4-pick-and-place/ ) had offered to sniff the bus at one point, but I don't remember if anything ever came of it. I think the best bet would be to ask someone with a Neoden 4 machine to do some captures.

Jason

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/b341b99c-bb60-491d-b4f8-82ab055a1b92%40googlegroups.com.

[Dylan Dodge]

That sounds like a good idea. I'll see if I can find someone to help me out. Thank you.

Dylan

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b341b99c-bb60-491d-b4f8-82ab055a1b92%40googlegroups.com.

[Jason von Nieda]

Let me know if I can assist. I'd be happy to throw some money at a can sniffer or something if needed. I'd love to have these feeders figured out.

Jason

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/36a64cec-1159-41a4-b0c2-44c920d3fcb3%40googlegroups.com.

[Dylan Dodge]

I ended up purchasing a CAN bus shield for the Arduino last week in the hopes of sniffing the bus, but there's just nothing coming off of the feeder. The best bet is definitely having someone sniff the bus on a Neoden 4 system through the initialization process as well as usage. I'll keep you updated on the progress. Thanks for the help.

Dylan

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/36a64cec-1159-41a4-b0c2-44c920d3fcb3%40googlegroups.com.

[Bdale Garbee]

On Thursday, July 25, 2019 at 10:33:06 AM UTC-6, Dylan Dodge wrote:

I ended up purchasing a CAN bus shield for the Arduino last week in the hopes of sniffing the bus, but there's just nothing coming off of the feeder

Be aware that CAN is an event-driven, message-oriented bus.  If it were me, I'd be working to attach something like an STLink/v2 debug dongle to the processor on the board to dump the code and have a look at it.  Sniffing a CAN bus without having a master (the host PnP machine) on the bus to generate transactions for you is likely to be frustrating if not futile. 

Bdale

[Jason von Nieda]

I can try dumping the code. I have an STLink/v2 and a feeder. I suspect it will be read protected, but worth a try!

Jason

--

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/66529008-17a2-4a13-886a-308ade508e7b%40googlegroups.com.

[Dylan Dodge]

Looking at the board, it seems that this bottom right corner would be where you would connect the STLink/v2? If so, I may look into getting one as well. Jason, if you are able to get anything off of the chip using it that would be great. Bdale, thank you for the advice, I am looking into getting someone with a machine to sniff the bus for me, but you are right, it was very frustrating trying to go through the CAN bus to get information.

Dylan

On Thursday, July 25, 2019 at 10:43:13 AM UTC-7, Jason von Nieda wrote:

I can try dumping the code. I have an STLink/v2 and a feeder. I suspect it will be read protected, but worth a try!

Jason

On Thu, Jul 25, 2019 at 12:41 PM Bdale Garbee <bd...@gag.com> wrote:

On Thursday, July 25, 2019 at 10:33:06 AM UTC-6, Dylan Dodge wrote:

I ended up purchasing a CAN bus shield for the Arduino last week in the hopes of sniffing the bus, but there's just nothing coming off of the feeder

Be aware that CAN is an event-driven, message-oriented bus.  If it were me, I'd be working to attach something like an STLink/v2 debug dongle to the processor on the board to dump the code and have a look at it.  Sniffing a CAN bus without having a master (the host PnP machine) on the bus to generate transactions for you is likely to be frustrating if not futile. 

Bdale

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

[Tim]

Yeah, they are the swdio, gnd, swclk and 5v pins. The stm32 was protected on mine.

[Dylan Dodge]

I found an interesting article on the security protection of the stm32

https://www.aisec.fraunhofer.de/content/dam/aisec/ResearchExcellence/woot17-paper-obermaier.pdf

The version of the stm32 in the feeder is F1 which only have a protection level 1. The code could potentially be obtained using Cold-Boot-Stepping. It would be interesting to see if this would yield anything useful.

Dylan

[bert shivaan]

Seems like it may be easier to just write new code that works the way you need it to. That is if you can at least flash it. I am pretty sure you can flash a uC PIC even if code protected. The thought is you can't steal the code, but you can re-flash it if you want/need. That could have changed but worth a thought. Seems like we have plenty of more than capable folks here to get the code done in no time at all.

--

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/76d73f0b-d219-44a6-a9ed-7e96a6422c3a%40googlegroups.com.

[Dylan Dodge]

Also, it seems their PCB layout has changed since your teardown. They are now using a DRV8313 to control the brushless dc motor.

Dylan

On Wednesday, July 24, 2019 at 11:07:34 AM UTC-7, Jason von Nieda wrote:

I posted a teardown of one a while back: https://imgur.com/a/osEGC

Near the bottom, there is an image where I identified most of the components.

I know that it's CAN bus, but that's about all. Since I don't have a Neoden 4 I was never able to hook it up and get it working so I could sniff the messages.

Jason

On Wed, Jul 24, 2019 at 12:52 PM Dylan Dodge <dcd...@ucsb.edu> wrote:

I am in the process of adding PnP functionality to a multi-tool printer design when I came across the Neoden 4 feeders. These feeders work perfectly within my space constraints, but I have been having trouble gaining functionality of one. Has anyone been able to hack one yet?

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

[Dylan Dodge]

If we were able to write our own code to the stm32 that would be ideal. Just need to do some more research on stm32 coding and CAN bus structuring. 

Dylan

On Thursday, July 25, 2019 at 12:28:08 PM UTC-7, cncmachineguy wrote:

Seems like it may be easier to just write new code that works the way you need it to. That is if you can at least flash it. I am pretty sure you can flash a uC PIC even if code protected. The thought is you can't steal the code, but you can re-flash it if you want/need. That could have changed but worth a thought. Seems like we have plenty of more than capable folks here to get the code done in no time at all.

On Thu, Jul 25, 2019 at 2:58 PM Dylan Dodge <dcd...@ucsb.edu> wrote:

I found an interesting article on the security protection of the stm32

https://www.aisec.fraunhofer.de/content/dam/aisec/ResearchExcellence/woot17-paper-obermaier.pdf

The version of the stm32 in the feeder is F1 which only have a protection level 1. The code could potentially be obtained using Cold-Boot-Stepping. It would be interesting to see if this would yield anything useful.

Dylan

On Thursday, July 25, 2019 at 11:17:15 AM UTC-7, Tim wrote:

Yeah, they are the swdio, gnd, swclk and 5v pins. The stm32 was protected on mine.

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

[Tim]

Using STM32CubeIDE and writing own firmware, I've managed to get the motor turning, not using pwm yet, and the opto interrupted working.

Need to sort the can bus code, and pwm motor control.

Wondering, do we need to sort the sprocket ratios out for tape distance moved for 1 motor revolution

[Dylan Dodge]

Tim that's great that you were able to get it working! I would assume having the opto sensor gets rid of the need to actually calculate the distance the motor must rotate. The opto interupt just stops the motor once the next hole on the tape reel is in position, so I see no immediate reason for doing those calculations. However, it might be useful to calculate it if there seems to be large enough inconsistencies with using the opto sensor. 

Dylan

[Tim]

That's what I was thinking with the opto. Reading the neoden 4 manual, it says you can set the feeder to move 2mm, so not sure how to precisely do that.

The motor is running via pwm now, so power can be controlled.

Just the can bus code to sort, then should be running. Planning to use the bigtreetech skr pro due to it have the can pins available.

[bert shivaan]

Do you need to use CAN if re-designing the control?

--
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/04876626-f660-4d13-8720-e810791069b5%40googlegroups.com.

[Tim]

Can bus is the only option with this feeder

[Dylan Dodge]

If neoden gives the option of 2mm travel, then they are using the sprocket ratios to calculate the amount of rotations needed. So, if you really need that functionality then it'll involve measuring the sprockets and doing some math. The problem is the consistency for the 2mm travel, but as long as the feeder "re-calibrates" by using the opto sensor every other time; we can expect that any error won't compound on itself. If you plan around using the bigtreetech skr pro, as long as the format and data rate is known, we can expect it to connect to any CAN system correct?

Dylan

[Jason von Nieda]

Using the opto you could "auto calibrate" by measuring the distance between two pulses and halving, right? Then the code will automatically handle any differences in sprocket dimensions.

Jason

--

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/afd61d13-b65b-4815-b333-9e48405b4ae3%40googlegroups.com.

[Tim]

In theory, any can bus should be able to connect to it, I'm lacking knowledge though

[Tim]

Jason, that could well be the way forward, thanks.

[bert shivaan]

Sorry to be dense here, But I am under the impression you are writing new code for the feeder? That means "CAN bus is the only option for this feeder" is not at all correct? If re writing the code to drive the feeder how does the feeder know what COMM's is being used? It is what ever you write in the code?

On Tue, Jul 30, 2019 at 2:24 PM Tim <timtr...@gmail.com> wrote:

Jason, that could well be the way forward, thanks.

--
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/6d9bd099-73f6-4dba-8054-e4f70b375686%40googlegroups.com.

[Jason von Nieda]

Bert: the feeder has a CAN transceiver hooked to the two data lines, so CAN it is.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNyjYvqvZ76BaW8oJDPJOVAG9KrMn7_QWnCsNLJ0ig2Whw%40mail.gmail.com.

[bert shivaan]

AHHH!!! The fine details!!

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jzug-97Bg9d%3DNZ2yL1%2BWsKKtBkA5iUxtR1s31U6_ALCMw%40mail.gmail.com.

[bert shivaan]

I am assuming the transceiver is the big 8 legged creature?

[Jason von Nieda]

Yep, the VP230 in this pic: https://imgur.com/XVQudSA

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNxaZ-QKZkDGz4frnH6NwNeUijchu1D%2B%3D5UcrHDMBSH%2Btw%40mail.gmail.com.

[Marius Liebenberg]

Does the CAN driver not just provide a differential pair? That will be similar to RS422/485 levels. The CAN part is in the stack that is used if you use the CAN feature to connect to those pins. You could drive a normal RS422 protocol through those same pins using a COMM or a software COMM.

On Tuesday, July 30, 2019 at 8:42:30 PM UTC+2, Jason von Nieda wrote:

Bert: the feeder has a CAN transceiver hooked to the two data lines, so CAN it is.

On Tue, Jul 30, 2019 at 1:41 PM bert shivaan <bert....@gmail.com> wrote:

Sorry to be dense here, But I am under the impression you are writing new code for the feeder? That means "CAN bus is the only option for this feeder" is not at all correct? If re writing the code to drive the feeder how does the feeder know what COMM's is being used? It is what ever you write in the code?

On Tue, Jul 30, 2019 at 2:24 PM Tim <timtr...@gmail.com> wrote:

Jason, that could well be the way forward, thanks.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6d9bd099-73f6-4dba-8054-e4f70b375686%40googlegroups.com.

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

[Tim]

The SN65HVD230 (can transceiver) is the feeders only connection to the outside world.

[Marius Liebenberg]

Agreed but they are just high frequency high slew differential line drivers. You can put any serial pulse train through them. So you dont have to use the CAN functionality of the STM but any other COMM interface or your own softserail driver if you wished. I would use the Arduino environment for STM and use the SoftSerial library connected to those two pins and write my own protocol or just use what others have done for their feeders.

[Jarosław Karwik]

CAN is simple. Just buy cheap USB dongle and you will be able to send and receive CAN frames. 

Usually CAN pins are not shared with serial port pins, so this allows complete reuse without hw changes.

[Dylan Dodge]

Has there been any more success with writing the firmware for the CAN bus? If you send me the firmware you created, I may be able to get that running.

[Tim]

My firmware has been put on the back burner for a couple of weeks. Got all the individual parts working, but not interconnected. Will get back onto it fairly soon

[Jason von Nieda]

Hi all,

For those interested in this project, a Twitter user has learned some additional information and published some bus dumps. The takeaway is that the bus is using CAN transceivers but UART framing (UART over CAN) at 500kbps.

Here's the Twitter threads with links to the dumps:

https://twitter.com/pakakezu/status/1176147224717402112

https://twitter.com/pakakezu/status/1176385190983344128

I've spent a few hours on it and I haven't come up with much yet. To me it looks like a 12 byte frame but Thomas (on IRC) has mentioned that it happens in bursts of 72 bytes. I wrote a program last night to step through one of the files checking various lengths and offsets for a match to the CRC-CCITT-16 that is used in the main NeoDen 4 protocol, but found nothing interesting.

So, if you are good at reverse engineering unknown binary protocols, have a look!

Also, feel free to join up on IRC to chat about this in real time if you like: https://webchat.freenode.net/#openpnp

Thanks,

Jason

On Thu, Aug 22, 2019 at 12:02 PM Tim <timtr...@gmail.com> wrote:

My firmware has been put on the back burner for a couple of weeks. Got all the individual parts working, but not interconnected. Will get back onto it fairly soon

--
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/edf9ce63-3a9b-4c35-bac2-6b1621527ec1%40googlegroups.com.

[Jason von Nieda]

Tom posted the below message, but when I was moderating the queue I accidentally deleted it. I'm reposting it for him:

-----

Hi Jason,

I looked at the log files. There seems to be a 15 bytes pattern in all files which repeats every 24 bytes:

00 6A 3A 00 03 00 16 00 00 00 00 49 00 65 87

To filter by this pattern, I looked at the data using the attached Python3 script (patternmatch.py). There are only 5 bytes which changes. Example:

[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 2, 3, 4, 15, 0, 0, 0, 72]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 0, 2, 15, 0, 0, 0, 201]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 0, 3, 15, 0, 0, 0, 177]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 0, 4, 15, 0, 0, 0, 217]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 1, 1, 15, 0, 0, 0, 204]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 1, 2, 15, 0, 0, 0, 68]

Except for the last byte (checksum?) all values are very small (e.g. IDLE 0-4, Calibrate 0-5). I can't see any logic behind it. To get a hint of it, i looked at the following two logfiles:

Idle1.log attached feeders 2-12,16-37,42-48, Unprogrammed 50

Idle2.log attached feeders 1-12,16-37,42-48

With attached Python3 script (finddiff.py) I printed out the differences between 24 byte long sequences matched with the mentioned pattern with this result:

packets in I1 and not in I2:
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 0, 2, 2, 2, 15, 0, 0, 0, 190]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 1, 4, 1, 2, 15, 0, 0, 0, 211]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 1, 0, 2, 15, 0, 0, 0, 197]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 2, 3, 4, 15, 0, 0, 0, 72]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 1, 1, 15, 0, 0, 0, 204]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 3, 3, 3, 3, 15, 0, 0, 0, 200]
packets in I2 and not in I1:
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 0, 2, 0, 3, 15, 0, 0, 0, 220]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 0, 2, 1, 2, 15, 0, 0, 0, 41]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 0, 2, 2, 4, 15, 0, 0, 0, 174]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 0, 3, 2, 4, 15, 0, 0, 0, 168]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 1, 1, 2, 3, 15, 0, 0, 0, 34]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 1, 2, 0, 2, 15, 0, 0, 0, 74]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 1, 2, 3, 3, 15, 0, 0, 0, 165]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 1, 3, 0, 1, 15, 0, 0, 0, 196]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 1, 3, 3, 2, 15, 0, 0, 0, 219]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 1, 3, 3, 4, 15, 0, 0, 0, 203]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 1, 4, 0, 3, 15, 0, 0, 0, 38]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 1, 4, 1, 4, 15, 0, 0, 0, 195]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 1, 1, 3, 15, 0, 0, 0, 48]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 1, 2, 3, 15, 0, 0, 0, 167]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 2, 2, 5, 15, 0, 0, 0, 189]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 2, 3, 3, 15, 0, 0, 0, 32]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 2, 5, 15, 0, 0, 0, 187]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 4, 0, 4, 15, 0, 0, 0, 203]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 4, 2, 2, 15, 0, 0, 0, 193]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 4, 3, 4, 15, 0, 0, 0, 92]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 3, 2, 0, 2, 15, 0, 0, 0, 33]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 3, 2, 0, 3, 15, 0, 0, 0, 89]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 3, 2, 1, 2, 15, 0, 0, 0, 172]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 3, 2, 1, 4, 15, 0, 0, 0, 188]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 3, 2, 2, 4, 15, 0, 0, 0, 43]
[0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 3, 4, 1, 5, 15, 0, 0, 0, 208]

Unfortunately, I have no idea what could be behind it and whether the approach with the 24 bytes (the mentioned 72 bytes = 3 packets?) is effective...

Tom

[Bernd Walter]

On Mon, Sep 30, 2019 at 05:20:38PM -0500, Jason von Nieda wrote:
> Tom posted the below message, but when I was moderating the queue I
> accidentally deleted it. I'm reposting it for him:
>
> -----
>
> Hi Jason,
>
> I looked at the log files. There seems to be a 15 bytes pattern in all
> files which repeats every 24 bytes:
> 00 6A 3A 00 03 00 16 00 00 00 00 49 00 65 87
>
> To filter by this pattern, I looked at the data using the attached Python3
> script (patternmatch.py). There are only 5 bytes which changes. Example:
> [0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 2, 3, 4, 15, 0,
> 0, 0, 72]
> [0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 0, 2, 15, 0,
> 0, 0, 201]
> [0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 0, 3, 15, 0,
> 0, 0, 177]
> [0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 0, 4, 15, 0,
> 0, 0, 217]
> [0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 1, 1, 15, 0,
> 0, 0, 204]
> [0, 106, 58, 0, 3, 0, 22, 0, 0, 0, 0, 73, 0, 101, 135, 2, 3, 1, 2, 15, 0,
> 0, 0, 68]

I havn't followed the progress on how the data was taken.
Is this just received data on the feeder?
With the CAN transceivers it should be a half duplex line, which makes the
direction on the transmission line indistiguishable.
But at the TTL side they should be separate.

At best you wouldn't use a PC programm, but instead watch the data with
a logic analyzer.
With 500kHz you can use pulseview with an ultra cheap chinese 24Msps 8ch
adapters.
That way you see the timing between the bytes as well.
Pulseview can decode UART signals as well, so you also get the parsed data.

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

[Al Yard]

It seems odd they aren't using the CAN protocol, I would have thought that would ideal for this application.   I traced the connection from the CAN driver chip to the MCU, and it is connected to PA9/PA10, which are the pins for USART1.   The MCU has a built in CAN controller, and the pins for the CAN can be moved to alternate pins, but PA9/PA10 is not one of the alternates for CAN.  So I guess we have a de-facto RS-422/485 instead. 

It wouldn't be a big deal to write up some code for this STM32 MCU, it's a fairly simple application.  But that means everyone who wants to use this feeder would have to flash new code, and not everyone has the tools to do that.  It would be nicer if we could figure out the protocol they are using, then it would be just a matter of plugging in the feeders to our buss.

Al

[Al Yard]

I put together some code for this feeder.  It is feeding the tape, the feed distance is determined from the photo-detector that detects each tooth.  I've added some motor speed ramping, but this may or may not be required.  It thumps a bit without it, but still works fine.

I haven't done up any code for the communication link yet.  That is the next step.

I have a few questions if anyone can help:

1.  Since this feeder is using a USART to feed a CAN buss driver chip, does anyone know off the top of their head if I could use a RS-485 adaptor on the other end?  Or is the CAN driver voltage/polarity not going to be compatible with RS-485 driver signal levels?

2.  How fast should this feeder feed?  I've got it feeding at roughly 4mm per second.  So it takes about 1 second to feed the next part.  Is this too slow?   We can of course send parameters to change the speed, but I was looking for something reasonable as a default.

3.  Where is the part pickup point on this feeder?  I'm not sure whether to detect off the leading edge of the tooth or the trailing edge.

3.  Does anyone know what voltage they are using to power this feeder?  And what voltage do they use on the cover tape puller?

I'm happy to share the code if anyone is interested.  I've never written to an ARM processor before, so am open to any suggestions as to better ways of doing things.

Al

[Jarosław Karwik]

You cannot connect RS485 driver  (phy) to CAN - it will not work.  You need to connect  serial port signal to CAN driver.

The easiest way to get such hybrid is to buy e.g. FTDI USD/TTL serial cable  ( ~ 10 Euro) and connect it to CAN driver chip ( or some module - there are  TJA1050 based which cost ~ 4 EUR). Use RTS signal to control data flow.

[Al Yard]

Thanks Jaroslaw,

I was hoping since they are both twisted pair and operate on similar principles, that I might get lucky.  But, it is not to be, so I will do up something along the lines of your suggestions.

In the long run, it's not a problem, I have to make up a long PCB to act as a buss for all the connectors to the feeders, so I can add a CAN driver and a USB/serial to the end of the board.  I just needed something simple in the meantime for development.

Al

[Marius M]

What is the voltage supply on neoden 4 autofeeder ? On the 4 pin connector I can see there is a red wire (+). Is it 12V ?

[betzt...@gmail.com]

I had a look at CAN and RS485 drivers. I was hoping they might be pin compatible, but it seems the standard for CAN is the mirror image of RS485 drivers. VCC and GND pins mirrored, R and D pins mirrored. The center pins would work (Diver enable and Receiver enable pins, as well as A and B). So close yet so far!!

[Michał Skorupski]

I wrote my own software for these feeders
https://youtu.be/tYYlHZHQJsc