Henriks machine, general presentation.

[Henrik]

Hi everyone,

New member here, Henrik is my name, Sweden is my location.

Several years ago I had this weird idea of building a pick and place machine, I'm sure you know what I'm talking about :-) At that time I, against better knowledge, decided to design and build it around parts I already had which is one of the reasons it looks like it does, another one is that at the time there really wasn't many DIY projects around finding the nitty gritty design details of comercial machines wasn't easy although I looked at lots and lots and photos on-line.

The machine made its first moves and picked up its first parts in November 2013 then the project sort of stopped, again. It's been one of those on-and-off type projects where nothing gets done for months and then all of sudden motivation sets in and/or you get a new idea or whatever. It's not finished, but I'm working on it again. I started playing with the drag-feeder type of thing but I never really liked the idea and started looking for a better way. After some time I found a bunch of FUJI intelligent feeders on EBAY and bought a bunch (20) of them, most of the dual lane 8mm ones. I spent sime time trying to figure out how to make them do their thing but didn't succeed so instead I designed my own control board to fit in the original ones place. This of course was a project on its own - but it's done and it works I just need to assemble boards for all the feeders - damn, one should have a pick and place machine.

On X and Y I'm using ballscrews with 10mm pitch driven by PMDC servo motorn thru a 2:1 belt reduction. Motors being driven by Granite Devices VSD-A (obsolete) drives. Z used to have a THK linear slide with a NEMA23 stepper. Pickup head was a NEMA11 stepper and I was using the old Neoden nozzles (the ones with the brass body) with my custom holder but I've ripped all that off in favour of a new belt driven dual nozzle head with NEMA8 and Samsung CP45 type nozzles.

Here's an overview of the machine as it currently sits (with ripped of head, THK slide behind the X-axis ballscrew and pickup stuff on the "table"):

And here's a photo of one of the feeders with the prototype control board fitted (it needed a rev B but that's done):

So, why am I here? Well, for the opnPNP software of course.

I'm a long time user of the Mach3 CNC controller application I Think I'm safe to say that I know it inside out. So initially I thought I'd use that and I've actually managed to get it to talk to Roborealm (machine vision application) but at that point (just as with the drag feeder) I realised it's going to a total hack - at best. Something better, designed for the purpose, is needed so I started looking. After (yet) quite some time and a couple of detours I've finally decided (Jason convinced me) to try openPNP. For that reason I've got a Smoothieboard X5 on order.

Anyway, what I know I'm going to need help with is to get my feeders integrated but I'll get to that later. Right now I just wanted to introduce myself and my "machine". I'll try to keep this thread "general" and start a new topic for the feeder integration and other specifics.

If anyone has any questions, if you want more details, or anything I'd be happy to provide whatever I can. I know there's quite a bit of discussion on feeder mechanics etc, perhaps some closeup photos of the FUJI feeders would be of interest?

OK, I'll stop now, thanks for letting me be a part of the community!

/Henrik.

¨

[Mark Harris]

Thats a really nice heavy duty looking machine! Well done for not going the cheapest possible route.

That feeder looks really crazy, can you tell us some more about it?

--
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/ab25a10b-93e9-4bc6-8514-31db2f5b5fdc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason von Nieda]

Hi Henrik, and welcome to the group!

We've already chatted quite a bit on the EEVblog forum, so I won't repeat myself here. I am curious, though. What cameras are you using on your machine? The one sitting under  it looks like it might be pointing at a mirror? Or is that just the detached head camera. 

I have a TODO on my short list for getting you a basic Smoothie driver. I'll probably have that checked in towards the end of the week. Let me know if you get to the point where you need to move the machine around before I check it in and I will hurry it up :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJMBTyQ8UjtKGdspjgRiHMN_fOZjus7pS%3DP5RYV7Y2vmbaDQEA%40mail.gmail.com.

[Rich Obermeyer]

Hi Henrik,

Definitely post more pictures and info on you feeder.

How to propose integrating it into openpnp?

[Henrik]

Thanks Mark!

The feeders are FUJI KG motorized feeders and I have 17 dual lane units for 8mm tape (34 lanes in total) and 3 single lane feeder for 12mm tape.

There's a metal sprocket that engages with the holes in the tape. The sprocket is driven by a linkage of arms, sort of like what can be found in an analog clock (I don't know the correct name for it). The linkade is driven by a camwheel on a stepper motor. One rotation of the stepper advances the the tape 4mm. A photo interruptor senses the "home position" of the arm linkage. The cover tape is pulled back and up across a pivoting arm and thru a set of plastic gears driven by DC motor. As the tape is advanced the spring in the pivoting arm keeps enough tension on the cover tape to expose the pocket in the tape fully. There's an opto-interruptor sensing when there's "slack" in the cover tape and when there isn't. You can see most of this in the photo above but I'll provide closeups if you want.

There's a small "control panel" in the handle of the feeder where you can manually select which lane ot feed, run a feed cycle and run the take-up motor. There are also three status LEDs for power, left/right and error.

On the single lane feeders there's no L/R button to select which lane. Instead there's a thumbwheel switch with which you can set how many times it should index for each feed command, anything from 4 to 60mm in 4mm steps. I don't know much about how they work in an actual FUJI machine but on the control board I designed I've got a discrete input for each lane, an open collector output signaling it's busy and an open collector output signaling feed error. There's also an RS485 tranceiver and I've implemented a stupidly simple protocol (but I can change it to anything) to command the feeders and ideally this is what I'd like to use to run them.

Unfortunately openPNP does not, yet anyway, have a way to command an external feeder like this but Jason tells me it shouldn't be too complicated to get going. I'm not a Java programmer myself but I'll certainly take a look at it once I've got the machine back in a moving condition. I really do think that a flexible way to send commands to an external feeder control would be a good addition to openPNP.

/Henrik.

 

[Henrik]

Thanks Jason,

No, no need to repeat yourself.

I've been playing around with various cameras but for the uplooking camera I'm currently aiming to use the one sitting parallel to the table looking into a 45° mirror. There's also Microsoft LifeCAM there but I hate the fact that it tries to do Everything for you. I want manual Control of focus, white balance, apparture etc otherwise it gets way to slow when it tires to adjust itself all the time. Yes, you can set it to manual but often times it forgets after a reboot - at least with Roborealm. For that reason I've moved to surplus analog cameras, larger sensors, larger lenses, manual control. This particular one is B/W, I don't know how well that plays with your current vision algorithms?

As for the downlooking camera I was experimeting with a cheap boroscscope thing but it keeps hanging all the time so I've orders another analog camera and a couple of different lenses that I will play with. I've got a cheap USB capture device to get the video in, I Think it should work with openPNP as it's detected by Windows without installing any additional software or drivers.

No rush with driver, I haven't received the Smoothie yet and I'm still missing parts for the head rebuild. I've got ways to go....

Thanks!

  

    /Henrik.

[Cri S]

What is your plan for rs485. Using analog MUX 32 or having external pin for location resolving of feeder.

[Henrik Olsson]

Yes,ideally I'd like to use RS485. A simple USB<->RS485 dongle for a few bucks, appears as an ordinary COM-port to the PC. A new feeder type in openPNP (Intelligent feeder) could be created where different interfaces could be added as they are needed. A way to select COM port and parameters and a way to specify what to send when each feeder is to be accessed. And a spcified, static, pickup location, like a tube feeder.

Everything could of course be hardcoded into openPNP but I can't for the life of me imagine I am the only one who needs a way to run intelligent feeders via a serial port so I'm trying to think of ways of doing it that will benefit others - even if it means I can't actually implement it myself but will have to rely on help and support from Jason and/or other developers.

At the moment (but it's just something I did to test) my feeders expects 6 ASCII bytes + CR where the first three represents the feeder to be used and the second three is the value 255-the feeder to be used. If lane 5 is to be indexed then I send the string 005250+CR.

Some way to handle error and busy signal from the feeders would be nice but not really needed initally.

Obviously more thoughts needs to be poured into this if it's going to be flexible (which I'd like i to be) and not specific to MY particular feeders.

Getting an external mux to signal each feeder discretely would still need some way send commands to the mux so then it's better (for me) to send commands directly to yhe feeders but a flexible aproach could be used with both.

An alternative, for me, is to program the feeders to listen to the comms between openPNP and the driver board and when it sees a command to go to the specifics feeders location it would index but that's a cludge to say the least.

/Henrik.

30 mars 2016 13:45:27 +02:00, skrev Cri S <phon...@gmail.com>:

What is your plan for rs485. Using analog MUX 32 or having external pin for location resolving of feeder.

--

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

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.

To unsubscribe from this group and all its topics, 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/868e34bd-6d20-4178-a1e6-4c12bacb5167%40googlegroups.com.

[Cri S]

You don't have understand me.
Normally exchangeable feeders need a way of localisation of where feeder is placed inside machine. Sure, you can decide to not allow loading and unloading the feeders and screw it directly on the table.
I have seen feeders that read out i2c memory. Without external eeprom there don't work.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1459341892927.99676.6974%40webmail7.
>
> For more opt

[Jason von Nieda]

Henrik (and others),

Until recently, most OpenPnP machines just had a single controller and thus a single COM port to deal with. As people build more complex and more interesting machines this becomes more and more of a hinderance. I've been working on a plan to address this and to additionally address the situation of having quite a few drivers but almost always needing to customize one for a new machine. So, here is what I am going to do in the next night or two:

1. Write a new GcodeDriver along the lines of https://github.com/openpnp/openpnp/issues/106

This will be a fairly simple driver that just connects to a port and echos pre-configured Gcode for all of it's actions. The user will be able to define the Gcodes that get sent and it will include some very basic variable substitution. I think that this driver will be able to run many different machines with very minor configuration from the user.

2. Add the concept of sub-drivers to this new GcodeDriver. 

Sub-Drivers are just additional copies of a driver embedded into the top level driver. The GcodeDriver will pass commands through to all of it's sub-drivers and these can process or ignore them. 

The purpose of this change is to make it very easy for a user to add and configure addons to their system, primarily around the concept of Actuators. Keep that in mind and I'll tie it all together at the end.

3. Add a new ReferenceAutoFeeder feeder class.

This will be a trivially simple feeder implementation that has a fixed pickup location and a reference to an Actuator by name, along with a value to send. When the feeder is commanded to feed it will lookup the actuator by name and then send the specified value. The value will be a double precision number.

Now, how does this all tie together? Using Henrik's machine as an example:

1. Configure a GcodeDriver and set the various Gcodes to any Smoothie specific ones. Probably the defaults will work out of the box. This handles motion control and it's COM port is connected to the Smoothie.

2. Configure a second GcodeDriver as a sub-driver. This one will have it's COM port connected to your RS-485 controller. The Gcodes will be configured to ignore everything except Actuator commands by simply setting all the Gcodes to null. For the Actuator Gcode it will be set to something like "$i$v" which are variable substitutions for actuator index and value.

3. Create Actuators in the machine config with a simple naming scheme like FEEDER1, FEEDER2, etc. Assign each an index that corresponds to your feeder's numbers on the bus.

4. Create any number of ReferenceAutoFeeders, each referencing one of the previously defined FEEDERn Actuators.

And in action:

* All OpenPnP commands are sent to the driver. The driver either processes them (if it has a valid Gcode string for that command) or passes them through to it's sub-drivers.

* Movement commands are handled by the master driver.

* Actuator commands fall through to the sub-driver. 

* When a feeder needs to feed it will look up it's actuator and send the defined value to it. This will first go to the master driver. The master driver's Gcode for actuate is set to null so it just passes the command to it's sub-drivers. The sub-driver gets the actuator command, substitutes the variables and then sends the result to the RS-485 port.

All in all, I think this will work for many of the machines out there and provides a reasonable level of extensibility going forward. It's not how I see drivers working a year or two now - I have other plans for a more HAL like layer eventually, but this is very easy to write now, doesn't require any changes to OpenPnP and will solve a lot of the integration issues that people see.

Keep in mind that this is just a single new driver, when it's all said and done. It won't affect or change anything about existing drivers and it doesn't preclude any other type of new driver being added.

Questions? Comments? Concerns?

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 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/1459341892927.99676.6974%40webmail7.

[Henrik Olsson]

Cri S,

OK, now I understand what you mean.

 

The feeders will be removable from the machine but at this point they will have to be placed back in the same location.

 

Currently, each feeder has a hardcoded ID (I could make it changeable but I currently don’t see the need for that). You could have a table in openPNP so that you could map feeder slots (pickup locations) to actual feeder ID but for me it would be enough to just be able to send a command down the bus.

 

I don’t see how I could randomly move feeders around and automagically have openPNP determine in which physical “slot” each feeder is – not with what I have now at least. An alternative is to build a single device with a serial port and whole bunch of discrete I/Os. That way each physical slot on the machine will have its own dedicated signal lines for feeder action and the actual feeders can go anywhere. Still need the serial though….but I see Jason has some ideas about that which I’ll read, dwell on and comment shortly.

 

/Henrik.

 

---

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJGcfUiegO7zCQ3hd6yyYvb%2Bsrwup%3D004qXKsx1%2BGfdgenSkvg%40mail.gmail.com.

[Mike Harrison]

On Wed, 30 Mar 2016 17:50:56 +0200, you wrote:

>Cri S,
>
>OK, now I understand what you mean.
>
>
>
>The feeders will be removable from the machine but at this point they will
>have to be placed back in the same location.
>
>
>
>Currently, each feeder has a hardcoded ID (I could make it changeable but I
>currently don’t see the need for that). You could have a table in openPNP so
>that you could map feeder slots (pickup locations) to actual feeder ID but
>for me it would be enough to just be able to send a command down the bus.
>
>
>
>I don’t see how I could randomly move feeders around and automagically have
>openPNP determine in which physical “slot” each feeder is – not with what I
>have now at least. An alternative is to build a single device with a serial
>port and whole bunch of discrete I/Os. That way each physical slot on the
>machine will have its own dedicated signal lines for feeder action and the
>actual feeders can go anywhere. Still need the serial though….but I see
>Jason has some ideas about that which I’ll read, dwell on and comment
>shortly.

If feeders are smart, and you want to be able to swap them around, the hard ID of the individual
feeder doesn't really matter - you probably need it as a way to talk to individual feeders on a
common bus, but that;s it. What matters is what parts it has loaded ( and maybe how many are left),
and where it is physically located at present. And maybe some generic feeder-type info ( e.g. how
long it takes to index, vib/tape/passive etc. )

When you initially set up a job and load parts into feeders, you want to say "feeder in position
<x>, you have 3000 of part 15k_0805", which is stored in an eeprom in the feeder.

When you run the job, it looks for feeders that contain each of the required parts and builds a
table of their physical position.

Of course you need a way to determine the phyisical position of each feeder.
An idea to make this work with all feeders on a common bus, avoiding the need for location-specific
connections etc. :
Each feeder has a switch or sensor that can somehow be actuated by the head.

When feeders are fitted, the head then goes and operates the sensor in each feeder position in turn,
and the feeder that senses the head shouts "Hey that's me", and sends its stored component data.

This idea could also avoid the need for a hardcoded feeder ID for bus addressing - once a feeder has
been detected, the system then tells the feeder its physical position for future addressing ( or
assigns it a bus-unique ID).

Another approach is to have globally unique feeder IDs for bus addressing, and it does an initial
poll to see who;s present, and asks the user where each one is located.
.

[obiwanke...@gmail.com]

485 / Modbus would work well for retrofiting older machines, with our PM460 the feeders are in a bank, the entire bank can be removed to change over to vibe feeders or waffle trays or whatever. Currently the head has a pneumatic plunger to press an air valve on each feeder to advance tape. Basically pickup bit drops and grabs part, then the tape knock drops and hits the mechanical air valve to advance. We can't really use the "tape Knock" advance when we change over to the dual pickup head. The idea at this time was to control each pneumatic feeder with a electric air valve for each feeder, controlled by a single pcb on each bank. Modbus would allow a 2 wire bus going to each bank. Modbus return packet could send back an acknowledge of command.

From the feeder thread, it looks like some of the smart feeders being designed would each individually be addressed by RS485 to advance, possibly a modbus command of how far to advance, and some feeders will be addressed by a controller that sets a I/O for each feeder in its group.

[Henrik Olsson]

Hi Mike,
Those are of course all excellent suggestions and ideas but for me,
personally and at this time, I don't see a need for openPNP automatically
tracking my feeders around. It would be nice and cool and all that but I
think it would involve a lot of development.

Since I'm more or less relying on Jasons good will to get me off the ground
here I'd personally settle for a way to send a serial command out and
possibly wait for a reply saying "Here you are sir, your part is served" or
"Sorry sir it appears I'm out of that one".

I've thought of the head operated sensor idea as a way to avoid having the
RS485 bus or discrete signals but it's another workaround IMO. I know that's
not what you're suggesting though.

The global addressing and having the user tell the software where each one
is located is probably the easiest to develop. You can have a table which
you can edit manually or openPNP can send a specific command that tells the
feeder with that ID to flash its LED or whatever and then ask the user in
which slot that feeder is.

But again, for me personally, I'd be happy to just have a simple way of
sending something out a serial port, and possibly waiting for a response.

But, if Jason decides to do something fancy I can adapt the code in my
feeders :-)

/Henrik.

--
You received this message because you are subscribed to a topic in the
Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
To unsubscribe from this group and all its topics, 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/6mtnfb1bjiq3qcqgmhqd54mnjqehk10jkb
%404ax.com.

[Rich Obermeyer]

@henrik, i think you got the right ideas here.  I previously did a vending machine using RS485 and this is vary close to the same thing.  Tell some remote mechanical sub assembly to spit out something of various size and shape and tell me when your done through a poll.

I would think the command string should have feeder ID, sub feeder, command byte, command parameter and then checksum to protect from errors causing issues later.

Sub feeder lets you use same circuit for many feeders.

You could have 255 feeders, 255 sub feeders, 255 commands to those feeders with an 8 bit parameter.  That should cover all the potential uses.

Send 0500010107cr, feeder 5, sub 0, led command, light on, checksum, carriage return.

Send 0501030817cr, feeder 5, sub 1, index, 8, checksum, cr.

Any command set is possible.

How are you setting the feeder ID on your current board?

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/1459341892927.99676.6974%40webmail7.

[obiwanke...@gmail.com]

I would recommend RTU mode Modbus as the protocol instead of rolling our own. PLC's and other off the shelf hardware use Modbus, there's probably an open source library that can be pulled into OpenPnP. For slave hardware Raspberry Pi and Arduino have libraries available. Packet size can be fairly large, 10 data fields would probably work ?
http://www.modbustools.com/modbus.html

[Cri S]

@obiwankenobi4444
use Modbus ASCII for parsing it on Com port.
Every memory collection on java scream you'r software timed RTU
communication up if
happens during transmission or if some asynchron event need be served
by the java code.
ASCII Modbus works fine, always.

2016-03-30 17:56 GMT, obiwanke...@gmail.com <obiwanke...@gmail.com>:

> I would recommend RTU mode Modbus as the protocol instead of rolling our
> own. PLC's and other off the shelf hardware use Modbus, there's probably an
>
> open source library that can be pulled into OpenPnP. For slave hardware
> Raspberry Pi and Arduino have libraries available. Packet size can be
> fairly large, 10 data fields would probably work ?
> http://www.modbustools.com/modbus.html
>
>
> On Wednesday, March 30, 2016 at 11:26:34 AM UTC-6, Maddog wrote:
>>
>> @henrik, i think you got the right ideas here. I previously did a vending
>>
>> machine using RS485 and this is vary close to the same thing. Tell some
>> remote mechanical sub assembly to spit out something of various size and
>> shape and tell me when your done through a poll.
>>
>> I would think the command string should have feeder ID, sub feeder,
>> command byte, command parameter and then checksum to protect from errors
>> causing issues later.
>> Sub feeder lets you use same circuit for many feeders.
>> You could have 255 feeders, 255 sub feeders, 255 commands to those feeders
>>
>> with an 8 bit parameter. That should cover all the potential uses.
>> Send 0500010107cr, feeder 5, sub 0, led command, light on, checksum,
>> carriage return.
>> Send 0501030817cr, feeder 5, sub 1, index, 8, checksum, cr.
>> Any command set is possible.
>>
>> How are you setting the feeder ID on your current board?
>>
>> On Mar 30, 2016, at 5:44 AM, Henrik Olsson <hen...@henriksplace.se

>> <javascript:>
>> >:

>>
>> What is your plan for rs485. Using analog MUX 32 or having external pin
>> for location resolving of feeder.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "OpenPnP" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to

>> openpnp+u...@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/868e34bd-6d20-4178-a1e6-4c12bacb5167%40googlegroups.com.
>> 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 <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/1459341892927.99676.6974%40webmail7
>>
>> <https://groups.google.com/d/msgid/openpnp/1459341892927.99676.6974%40webmail7?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 a topic in the
> Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
> To unsubscribe from this group and all its topics, 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/10bc7931-ffdc-4513-a942-2d9aee5737d1%40googlegroups.com.

[Rich Obermeyer]

MODBUS is rather overkill for a simple feeder network.  

None of the existing commands relate to a feeder so you would have to roll your own command set anyway.

Feeders typically have sub feeders to reduce electronics.  Modbus does not handle that case.

Running a rasberry Pi as a modbus feeder controller seems like a V8 on a go-kart to me.

The existing controller is a trivial PIC processor.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/10bc7931-ffdc-4513-a942-2d9aee5737d1%40googlegroups.com.

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

--

Rich

[Mike Harrison]

On Wed, 30 Mar 2016 11:26:57 -0700, you wrote:

>MODBUS is rather overkill for a simple feeder network.
>None of the existing commands relate to a feeder so you would have to roll
>your own command set anyway.
>Feeders typically have sub feeders to reduce electronics. Modbus does not
>handle that case.
>Running a rasberry Pi as a modbus feeder controller seems like a V8 on a
>go-kart to me.
>The existing controller is a trivial PIC processor.

I'd agree - all you need are some simple ASCII strings.
Unless there are existing bits of Modbus hardware that you want to interface, there's no need for
anything as complex, and no need to pull in and learn someone's library to deal with it.
As you'll be so far inside RS485 cable length and speed specs you won't ever see data errors so
checksums wouldn't be necessary. (some may disgree but my experience doing megabaud over tens of
metres of cat5 tells me that a few hundred kbaud over a few metres is just going to work 100%)
With an ASCII protocol, simply filtering on character range and message length would be more than
enough.
If in doubt, keep it simple! Resources are always finite, so building a belt-and-braces system just
isn't justifiable.

[Henrik Olsson]

I’m using an 8bit PIC as the controller in the feeders and although I’ve written my own MODBUS stack (RTU) for that family I agree with Chris, it’s overkill and not really suited. If it was already built into openPNP and was ready to use I could certainly adapt but I don’t think we should go in that direction.

 

My current 6 byte ASCII protocol as simple as it is works fine, it doesn’t have an actual checksum or CRC but it still verifies that the first part (005 for feeder 5) matcher the second part (250 for feeder 5). But then again, that’s just me, others might want it different and I can adapt at my end.

 

/Henrik.

 

 

---

Från: ope...@googlegroups.com [mailto:ope...@googlegroups.com] För Rich Obermeyer
Skickat: den 30 mars 2016 20:27
Till: ope...@googlegroups.com
Ämne: Re: [OpenPnP] Re: Henriks machine, general presentation.

 

MODBUS is rather overkill for a simple feeder network.  

[Henrik Olsson]

Sorry, I meant to say I agree with Rich, got the names mixed up….

 

---

Från: ope...@googlegroups.com [mailto:ope...@googlegroups.com] För Henrik Olsson
Skickat: den 30 mars 2016 20:49
Till: ope...@googlegroups.com
Ämne: [OpenPnP] Re: Henriks machine, general presentation.

 

I’m using an 8bit PIC as the controller in the feeders and although I’ve written my own MODBUS stack (RTU) for that family I agree with Chris, it’s overkill and not really suited. If it was already built into openPNP and was ready to use I could certainly adapt but I don’t think we should go in that direction.

 

My current 6 byte ASCII protocol as simple as it is works fine, it doesn’t have an actual checksum or CRC but it still verifies that the first part (005 for feeder 5) matcher the second part (250 for feeder 5). But then again, that’s just me, others might want it different and I can adapt at my end.

 

/Henrik.

 

 

--

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
To unsubscribe from this group and all its topics, 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/DDB9A33274A0403986B6EB35B12DE059%40Office.

[Mike Harrison]

On Wed, 30 Mar 2016 11:26:57 -0700, you wrote:

>MODBUS is rather overkill for a simple feeder network.
>None of the existing commands relate to a feeder so you would have to roll
>your own command set anyway.
>Feeders typically have sub feeders to reduce electronics. Modbus does not
>handle that case.
>Running a rasberry Pi as a modbus feeder controller seems like a V8 on a
>go-kart to me.

Another thing - feeders take time to complete a feed operation, however as this time should be very
predictable for a given type, I think simply being able to tell the system how long a feed will take
(baseline <t1> plus <t2> * number of indexes) is simpler than doing 2-way comms to find when a feed
is complete.

Especially when you consider issues like whether you feed before or after a pick, as in the former
case (e.g to keep maximum cover tape in pace and reduce risk of bounce-out from vibration) you want
to overlap the feed time with time to get the head to the feeder, but need to know that the feeder
is ready before picking. This could get quite messy with a polled system, but very easy with simple
timings.

One thing the RV does, which I don't think actually gives much benefit, is for multiple indexes, it
does one index after pick, and the rest after recognition. The logic being that it will
automatically get itself in sync by feeding one index at a time until you get a good pick.
As it does all the remaining indexes before placing, it actually slows things down ( though this is
a limitation of their implementation, not the general principle)
The only situation where it might make sense is if you have a flaky feeder that sometimes misses
single indexes, so it gets itself back in step. But better to make the feeders more reliable!

[Rich Obermeyer]

Not seeing how polling for a feeder (micro seconds) complete on RS485 could add any significant delay to the process that's seconds already.  What else is going on while you are waiting for a feeder to advance?

This loop would simplify the driver process as well.

Assuming advance times is poor assumption when you consider all the tape sizes.  Requiring the user to input the delay is just more useless homework per feeder during setup.

--
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/cl7ofbpqgenhftnu1gvbvellqb2srusm74%404ax.com.

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

--

Rich

[obiwanke...@gmail.com]

The specs on Modbus look fairly intense, actual code is not really much more difficult than sending a string of bytes out.

Is this bus just feeders, or any external device not controlled by the motor controller ? If it's just a simple feeder control then an ASCII string with CRC would work fine, or could it one day include a conveyor system that could stretch out ~20 feet, tied into stencil printer, etc. ?

[Mike Harrison]

On Wed, 30 Mar 2016 12:13:14 -0700, you wrote:

>Not seeing how polling for a feeder (micro seconds) complete on RS485 could
>add any significant delay to the process that's seconds already. What else
>is going on while you are waiting for a feeder to advance?

I was taking about complexity, not delay. Having said that. though turnround delays on RS485 are
minimal, once they go through a USB-485 converter, especially a cheap one that is full speed, not
high speed, and if its timeouts haven't been optimised, turnround times can get surprisingly high -
well into many tens of mS per transaction.
If your feeders like to keep the cover tapes on, you want to be moving towards the feeder, but want
to make sure the feed is done before picking.
Less of an issue where you feed immediately after pick.

>This loop would simplify the driver process as well.

How is a process of polling simpler than knowing that as long as a configured time has passed since
sending a feed command, it will be ready.
As soon as you have 2-way comms, you have to think how to deal sensibly with getting the reply, and
deciding what to do if you don't, all while you're doing other things like moving teh head or maybe
changing a nozzle en route.
And testing that code under enough conditions to be confident that it works.

>Assuming advance times is poor assumption when you consider all the tape
>sizes. Requiring the user to input the delay is just more useless homework
>per feeder during setup.

It's per feeder type. Most users will have a small number of feeder types.

Yes in an ideal world everything would run on highly flexible protocols over fibre with error
correction, but in the real world we just want to get something that works, and not be any more
complicated/time consuming to implement than it needs to be.

[Cri S]

This are professional feeders for high end machines that are able to
feed at rate of 40-46ms interval.
The feed command need to be issued after picking the component, now if you have
two nozzles and distance is 40mm from idling point to the picking
point for the second nozzle,
it need (using 16 spocket without reduction) 208 ms to get to the pick
up position using
trapez acceleration, using jerk limited acceleration it need more time.
Now if delay is 150ms, who cares, it don't change anything.


2016-03-30 19:42 GMT, Mike Harrison <mi...@whitewing.co.uk>:

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
> To unsubscribe from this group and all its topics, 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/6aaofb15qiv86no7ft9c0hc6n16513drf0%404ax.com.

[Cri S]

smoothie board have modbus (in)compatible implemention able to trigger
over 512 feeder.
The microcontroller need only to have circular buffer of 7 bytes and
compare it with the
(2-8) precomputed modbus messages, no need for crc calc.
0x01, 0x05, 0x02, 0x00, 0x00, 0x00, 0x00
byte 3 and 4 contains the id value and 5 and 6 the offline computed
crc checksum.
It works too if ignoring the crc and checking only 5 bytes.
No need for checking timeout or other things. and if there is positive
match, the array need
to be erased, or at least the second byte set to zero.
Now there are 655 valids id, if every feeder have 4 id, for
(led-)on/off/blink/feed , there
could be 163 configured feeder, reserving 7 for tray 7-pos tray
changer there could be 162
feed lanes. Maybe it's better to add more codes for leds add if
allowing 6 codes / lane,
it's possible to have 102 feeder lane (dual feeder = two lanes) and 8
pos tray changer.



2016-03-30 20:00 GMT, Cri S <phon...@gmail.com>:

[Henrik Olsson]

Jason,

I’ve read your post a couple of times now and in general I think it looks good. How flexible it becomes obviously depends on how the variable substitution works, what you allow access to, if static “text” can be included and how you “build” or “format” what actually goes out.

 

So, an actuator is always associated with a G-code while a feeder necessarily isn’t and that’s why we’d have to define one actuator and one feeder – for each feeder – in order for the subdriver to have something to act on in order to have it send the data our? It seems a bit convoluted but totally workable but why not include it directly in the AutoFeeder? Would doing that make it less flexible?

 

I’m sorry if this is obvious to people used to the internals of openPNP.

 

Why the double precision number and how exactly would it be sent, as the 8 byte binary it actually is or converted to ASCII and if ASCII would it always have the same number of characters?

 

By the way, how does one actually add or create a nozzle or an actuator in the Machine Setup tab? I can’t seem to do anything…

 

/Henrik.

 

---

[Michael Anton]

There was a discussion on the Firepick Delta forum about using QR codes to locate feeders with the down looking camera.  Perhaps that would be an easy solution to allow feeders to be put anywhere, and the system could then identify the feeder number from the QR code on the feeder.  Of course a mapping of feeder number to part loaded would still be required in OpenPnP, but we need that even if the feeders are in fixed locations.

Mike

[Michael Anton]

Jason,

This all sounds like a really great approach, and very flexible.

Mike

[Jason von Nieda]

Hi Henrik,

Glad you saw the post - I was starting to wonder if it got lost in the deluge :)

Very good questions! I'll address them inline:

I’ve read your post a couple of times now and in general I think it looks good. How flexible it becomes obviously depends on how the variable substitution works, what you allow access to, if static “text” can be included and how you “build” or “format” what actually goes out.

The plan is for variables to be quite simple to start and then we'll see what works and what doesn't and iterate on it. The first pass will just be in the form of {property_name:format}. The property_name will reflect the name of a value passed in to the formatter and the format will be printf style.

So, for the "actuate" gcode, for instance, the variable formatter will be passed something like:

actuator_name : A1

actuator_index : 15

double_value : 150

boolean_value : true

So, if you wanted to control your feeder you could just do something like:

"{actuator_index:%03i}{double_value:%03i} which would result in output of "015150", for instance.

The different operations would have different variables available to them that make sense in the context of that operation.

This isn't set in stone yet, it's just the current thinking.

 

So, an actuator is always associated with a G-code while a feeder necessarily isn’t and that’s why we’d have to define one actuator and one feeder – for each feeder – in order for the subdriver to have something to act on in order to have it send the data our? It seems a bit convoluted but totally workable but why not include it directly in the AutoFeeder? Would doing that make it less flexible?

Let me give a bit of background first:

In OpenPnP no high level object (Nozzle, NozzleTip, Camera, Actuator, Head) is associated with Gcode. Gcode only lives at the Driver layer. The Driver is responsible for mapping high level object actions (Nozzle.moveTo, Nozzle.pick, Nozzle.place, Actuator.actuate, etc.) to machine specific functions (Gcode, JSON, network, etc.)

Most of the existing drivers are pretty simple. moveTo operations just spit out a G1 Gcode, pick and place use Mcodes to turn outputs on and off, etc.

So, with that background, to answer your question: My description of how that feeder system could work was just one example, and off the cuff. What would actually probably make more sense is just creating a single Actuator called FEEDER and then have the value that it is sent trigger the appropriate feeder. So, you set up that Actuator and then when you set up your individual feeders you'd just specify Actuator FEEDER and value 0 for the first one, value 1 for the second, etc.

These layers add some complexity to configuring a system, but in the end they also provide flexibility to be able to handle very disparate systems. By decoupling the generic concept of an Actuator from how it actually does it's work we are able to map that Actuator concept to all kinds of weird physical hardware.

I promise, though, after I've written this I think you'll find it's pretty easy to configure. And you only have to do it once :)

 

Why the double precision number and how exactly would it be sent, as the 8 byte binary it actually is or converted to ASCII and if ASCII would it always have the same number of characters?

The Actuator interface has two functions: actuate(Boolean) and actuate(Double). I wrote this interface quite a long time ago and at the time I just kind of guessed as to what we'd need. It's served us well so far so I haven't felt the need to modify it.

 The way the output is formed will be based on how you define the output string re: the variables I discussed above. So, you'd just integer values and format them as integers and it should all work out fine.

Again, I think this will make more sense once I can actually show a working configuration using it. Look for that in the next night or two.

By the way, how does one actually add or create a nozzle or an actuator in the Machine Setup tab? I can’t seem to do anything…

Unfortunately this is one of the last things that you still have to do by modifying the configuration files by hand. I just haven't prioritized writing a UI for it since it's typically only done one time for a given machine. 

You can look at https://github.com/openpnp/openpnp/wiki/FAQ#where-are-configuration-and-log-files-located to see where the config files are located. You'll want to edit machine.xml.  If you open it up it should be pretty self explanatory but if you have questions just ask. You can do most things by cut and paste but there is one "gotcha". Make sure you give each object a unique ID. It doesn't have to be complicated, just unique within it's individual list. Many of the existing objects in the default config use GUIDs (long hex strings) but an ID can just be "0", "1", etc.

Jason

[Henrik]

Jason, while playing around with the configuration files I managed to add a second nozzle and additional nozzle tips by editing the Machine.xml file. However I failed to add an actuator which is not part of the head. I tried twice and openPNP refused to start since I apparently corrupted the file. There doesn't seem to be a non head referenced actuator in there so the format isn't that clear to me. I'll need to play more with that.

 

The more I read and think about your suggested approach with the sub-driver the more sense it makes and if you get that into openPNP I can certainly make it work at my end and there's nothing preventing people from building conveyors and what not. It probably won't be easy to adapt to existing stuff with various protocols though.

My Smoothieboard is still in transit (bloody Swedish post is messing about) but I did finally get the NEMA17 motor for driving the dual head design so I started assembling that, here's a couple of photos:

All machined parts. Bunch of extra holes in the back plate for whatever might be needed, cameramount, circuit board etc.

A bit of paint and the drive belt attached.

Head backplate with linear rails (7mm), motor and mount for idle pulley.

Head partly assembled. Opto interruptors to sense the home position. Still waiting for the new hollow shaft NEMA8 motors.

 

/Henrik.

 

[Jason von Nieda]

Hi Henrik,

First, let me say WOW! That head looks great! Please tell me you've been working on it for months and not days, because otherwise I am going to feel really bad about my mechanical skills.  :) Well done!

I mostly finished the first version of the new driver last night. It needs one more night of polish and then I'll release it. I think it's going to work out really great. I'm using my existing machine as a benchmark to see if I can do all the same things on it with the new driver as I could with the old, very customized one. So far, so good. The only thing I can't do is control both Z axes due to the non-linear cam on my machine. This won't be an issue for belt driven heads like yours. 

The beauty of this sub-driver concept is that even if the definable Gcode strings + variables won't suit an existing protocol, it will be trivially simple to write a driver to handle whatever protocol you can dream up. The code is extremely simple. For example, here is a complete driver that you can drop into the sub-driver list to control a device:

public class SampleDriver extends NoopSerialDriver {

    @Override

    public void actuate(ReferenceActuator actuator, double value) throws Exception {

        // Send a command

        List<String> responses = sendCommand("SOMETHING WEIRD THAT CANT BE EXPRESSED IN GCODE");

        

        // See how it went

        for (String response : responses) {

            if (response.contains("PANIC")) {

                throw new Exception("It didn\'t work!");

            }

        }

    }

}

That little bit of code gets you a first class Driver in OpenPnP. All the details about the serial port are handled for you, including the GUI configuration of the port and baud rate.

I really think this is going to make integration of pretty much any type of device very easy. I'm very excited about it!

Before I started coding last night I laid out a three phase plan for this driver. Last night I mostly completed the first phase.

The plan is:

## MVP

* Four axes

* One nozzle

* Camera doesn't move in Z

* Definable Gcode

* Variables in Gcode

* Sub-Drivers

* Simple Actuator support (one gcode, variables)

* Home position (user will need to set it to non zero if they want it, and send gcode to make sure controller is in sync)

 

## MVP + 1

* Definable axes

* Define axes like X, Y, Z, C1, C2.

* Map HeadMountables to a list of Axes like:

* N1 -> X, Y, Z, C1

* N2 -> X, Y, Z, C2

* CAM1 -> X, Y

* Axes can have Transforms applied that mutate machine positions. Something like:

* double transform(HeadMountable, double position)

* If you map more than one device to the same axis a transform is required on that axis.

* Mapping of HeadMountables to Axes

* Axis transforms

* Solo moves for axes

 

## MVP + 2

* Map HeadMountables to Sub-Drivers

* Improved actuator support (gcode per name, variables)

* Get current position on startup

* Position tracking during moves

My plan is finish all three phases by this weekend and get it out the door. An unlisted Phase 4 will be to try to replace as many of the existing drivers with this one (plus a gcode profile) as possible so I can eliminate duplicate code.

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 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/5691f628-fe5c-4084-9347-e2c52d35f351%40googlegroups.com.

[Jason von Nieda]

Henrik,

Sorry, I just realized I failed to address your Actuator comments. 

You can add this block to either the head specific actuators list (openpnp-machine -> machine -> heads -> head -> actuators) or the machine global actuators (openpnp-machine -> actuators):

               <actuator class="org.openpnp.machine.reference.ReferenceActuator" id="A1" name="A1" index="0">

                  <head-offsets units="Millimeters" x="0.0" y="0.0" z="0.0" rotation="0.0"/>

                  <safe-z value="0.0" units="Millimeters"/>

               </actuator>

Once you add it you should be able to configure it from within the UI.

If you are struggling with a machine.xml that won't load feel free to send it over and I'll take a look.

Jason

[Henrik Olsson]

Jason,

Sorry for the late reply and thank you very much for the compliments on the head rebuild. It's been more than a couple of days yes, but still not weeks I don't think. I don't know your mechanical skills but what you possibly lack, which I doubt you do, you make up in code writing skills :-)

I managed to add the actuator part to the machine.xml file and have it show up in the tree-view in OpenPnP but there's nothing to configure on the right hand side - which sort of makes sense since a non head mounted actuator won't have a safe Z or offset would it? But why should the data then be included in the configuration?

Still so much to learn....

I see you're making great progress on the new driver, I'll read thru the other thread and possibly comment there. Could you quickly run thru, or point me to a tutorial on how I'd go about to "pull it into" Eclipse - that's (also) totally new teritory for me :-(

It appears as if the Swedish post have lost my Smoothieboard. I have a tracking number but they don't know where it is. Took three days from France to Sweden and now 9 days here.

/Henrik.

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

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.

To unsubscribe from this group and all its topics, 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/CA%2BQw0jw%3Duze9oz7Ez3OzWwr8dh8nCtqz5OdAwsbEdK8jtgUfCA%40mail.gmail.com.

[Jason von Nieda]

Hi Henrik,

I managed to add the actuator part to the machine.xml file and have it show up in the tree-view in OpenPnP but there's nothing to configure on the right hand side - which sort of makes sense since a non head mounted actuator won't have a safe Z or offset would it? But why should the data then be included in the configuration?

I've just pushed a change to the develop branch that adds the index field into the configuration pane for actuators. This is something that was missed previously.

You are right that since the actuator isn't head mounted it doesn't have safe-z or offset. The reason that it shows in the config is because I use a serialization framework to create the config and all it does is just read the fields defined on each class. I use the same class for head mounted actuators as I do machine mounted ones, so the fields end up in the config but they are just ignored. 

 

Still so much to learn....

I see you're making great progress on the new driver, I'll read thru the other thread and possibly comment there. Could you quickly run thru, or point me to a tutorial on how I'd go about to "pull it into" Eclipse - that's (also) totally new teritory for me :-(

Do you already have the project set up in Eclipse? If not, check out https://github.com/openpnp/openpnp/wiki/Getting-Started-with-Eclipse

If you do, and you checked it out of Git like the instructions say just right click on the project in Eclipse, select Team from the popup menu option and then select Pull. This should pull down the latest code from the branch you checked out, which should be develop.

That being said, my hope is that with this new GcodeDriver you won't actually have to write any code, just configuration.

 

It appears as if the Swedish post have lost my Smoothieboard. I have a tracking number but they don't know where it is. Took three days from France to Sweden and now 9 days here.

Ack! Sorry to hear that. Hope it shows up soon!

Jason

 

[Henrik Olsson]

Thanks Jason,

Yes I have the project setup in Eclipse as per your nice instructions. I'll try to get the changes pulled in.

And, like magic the Smoothieboard turned up yesterday :-)

Still got some work to do to actually connect it up and a lot of reading on how to configure it but I'll get there.

/Henrik.

--

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

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.

To unsubscribe from this group and all its topics, 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/CA%2BQw0jwghOEqrqq2gMTzvXCEmUNmJU55AZyD3hjKr3D2y5g-gw%40mail.gmail.com.

[Henrik]

I thought I'd share a bit of what I've been doing the last couple of weeks.

I ordered a couple of different CCTV lenses to try on the head mounted camera, I think I've settled on using a 12mm F1.2, made a ring-light of it from one the cheap angle-eye LED rings and a couple of pieces of white plexi:

In the end I don't know.... even at very low current there's a clear reflection, like a halo, in the image from the camera. I don't Think it'll matter for finding fiducials though, will have to wait and see.

Bottom vision is using a monochrome Pulnix TM6 camera and I'm using a cheap USB capture dongle to grab the images. The camera is mounted parallell with the bed of the machine is looking into a 45° first surface mirror and up thru a mock-up of the illumination:

Just some White LED strip at an angle but the I have big hope on that the images produced by this setup will work fine with the vision pipeline in OpenPNP. If you're reading this Jason I'd appreciate a comment on if you Think this is workable or if I should throw it out and get an ELP like everybody else :-)

(These are for individual images cropped and stitched together - NOT 4 nozzles in one image)

The head rebuild is mechanically complete. Two Samsung CPP45 style nozzles on NEMA 8 motors. One of the motors had a badly bent shaft but I managed to straighten it. The "nozzle adapters" are just some PCB spacers drilled and reamed too which I've then epoxy glued the actual nozzle holders. This allowed me dial in the runout of the holder quite good. That doesn't mean the nozzles run 100% true though.

I've also designed a PCB that will be mounted on the head. It's got the pressure sensors and drivers for the solenoid valves and LED-light. There's a microcontroller and RS485 tranceiver on the board thru which OpenPNP can control the valves, LEDs and poll for current vacuum pressure. I decided to let the microcontroller on this board drive the valves and LEDs instead of running discrete wiring from the motion controller up to the head. Jasons new sub-driver concept should allow this - I hope :-)  There's also simple feed-thru connections for nozzle steppers, Z-stepper, Z-limits and video. And since I had the space I included stuff for a second camera.

Last but not least I've finally machined one of the feeder racks, this will hold the 17 dual lane feeders that I've currently got. This task turned out the be a total pain in the butt and didn't quite turn out to what I hoped it would. I was shooting for a tight fit so that the feeders would be held in place by friction between the rack and the feeder itself. An early prototype indicated this would be possible but nah, it wasn't easy. It's either too tight making the thing impossible to get in (and/or out) or just a tad to little allowing the feeder to "swing" a bit from side to side (the feeders are quite large and it's a long way from the base to the actual part pocket). I need to give this some thought and see what I can come up with. Anyway, the rack will consistently locate the feeder(s)  - and it looks nice (once the black marker stripes are cleaned off.....)

Now I'll get back to playing around with the Smoothie and thinking about the issue with the feeder rack while I'm waiting for the bare PCBs to show up - which will take a couple of weeks.

/Henrik.

[Anthony Webb]

Thanks for sharing!  Keep the updates coming, you're doing some nice work!

--

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/4eac75ed-d079-4d33-94c3-9749b5cabb06%40googlegroups.com.

[matt]

I'm liking the belt to raise / lower each head idea - is that your own
invention? Guessing driving the left one down lifts the right one and
vica versa? Simples!

On 2016-05-25 19:14, Anthony Webb wrote:
> Thanks for sharing! Keep the updates coming, you're doing some nice
> work!
>
> On Wed, May 25, 2016 at 12:06 PM, Henrik <hen...@henriksplace.se>
> wrote:
>
>> I thought I'd share a bit of what I've been doing the last couple of
>> weeks.
>> I ordered a couple of different CCTV lenses to try on the head
>> mounted camera, I think I've settled on using a 12mm F1.2, made a
>> ring-light of it from one the cheap angle-eye LED rings and a couple
>> of pieces of white plexi:
>>

>> [1]
>>
>> [2]

>>
>> In the end I don't know.... even at very low current there's a clear
>> reflection, like a halo, in the image from the camera. I don't Think
>> it'll matter for finding fiducials though, will have to wait and
>> see.
>>
>> Bottom vision is using a monochrome Pulnix TM6 camera and I'm using
>> a cheap USB capture dongle to grab the images. The camera is mounted
>> parallell with the bed of the machine is looking into a 45° first
>> surface mirror and up thru a mock-up of the illumination:

>> [3]

>>
>> Just some White LED strip at an angle but the I have big hope on
>> that the images produced by this setup will work fine with the
>> vision pipeline in OpenPNP. If you're reading this Jason I'd
>> appreciate a comment on if you Think this is workable or if I should
>> throw it out and get an ELP like everybody else :-)
>>

>> [4]

>> (These are for individual images cropped and stitched together - NOT
>> 4 nozzles in one image)
>>
>> The head rebuild is mechanically complete. Two Samsung CPP45 style
>> nozzles on NEMA 8 motors. One of the motors had a badly bent shaft
>> but I managed to straighten it. The "nozzle adapters" are just some
>> PCB spacers drilled and reamed too which I've then epoxy glued the
>> actual nozzle holders. This allowed me dial in the runout of the
>> holder quite good. That doesn't mean the nozzles run 100% true
>> though.
>>

>> [5]

>> [6]

>>
>> Now I'll get back to playing around with the Smoothie and thinking
>> about the issue with the feeder rack while I'm waiting for the bare
>> PCBs to show up - which will take a couple of weeks.
>>
>> /Henrik.
>>
>>>
>>
>> --
>> 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/4eac75ed-d079-4d33-94c3-9749b5cabb06%40googlegroups.com

>> [7].
>> For more options, visit https://groups.google.com/d/optout [8].

>
> --
> 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/CALsNZy19_uWjtw_KaqnPf5ZNfOCjyYq-1JqHfuTJSZ-Lc8U9RA%40mail.gmail.com
> [9].
> For more options, visit https://groups.google.com/d/optout [8].
>
>
> Links:
> ------
> [1]
> https://lh3.googleusercontent.com/-B6EUK6XWN_o/V0XgwJllj3I/AAAAAAAAADQ/mQC5DLRUowA17_oZu-R6YcAN9izVj25bACLcB/s1600/Ring%2Blight%2B-%2B1.jpg
> [2]
> https://lh3.googleusercontent.com/-ByA2bBS-rI8/V0Xg6CLH6mI/AAAAAAAAADU/5ITkY-fJ7IkN6yUp9SsmVSzX6ADYfwesgCLcB/s1600/Ring%2Blight%2B-%2B2.jpg
> [3]
> https://lh3.googleusercontent.com/-hgscKQMeZtQ/V0Xh876CfhI/AAAAAAAAADk/Yj9VsiZyqI8fK9fwlT98ILjvq6L44zJ-gCLcB/s1600/Bottom%2Bcamera.jpg
> [4]
> https://lh3.googleusercontent.com/-DTuVqKk62_o/V0XitG12dEI/AAAAAAAAADs/RXBz_rvORQcbzvMw7aDeMkGxlTE0p_xgwCLcB/s1600/Sample%2Bimages.png
> [5]
> https://lh3.googleusercontent.com/-nGNYX4awjK0/V0Xj72usuPI/AAAAAAAAAD4/EPuwbSCIO3IAU_RR04w06JWwmafxgftwgCLcB/s1600/New%2Bhead%2B-%2B1.jpg
> [6]
> https://lh3.googleusercontent.com/-jBBQP_QxPk0/V0Xnm8GptbI/AAAAAAAAAEE/ROpQUpOBVJcXPzgeYzcAnjr7u8qDlNumgCLcB/s1600/Feeder%2Brack%2B-%2B2.jpg
> [7]
> https://groups.google.com/d/msgid/openpnp/4eac75ed-d079-4d33-94c3-9749b5cabb06%40googlegroups.com?utm_medium=email&amp;utm_source=footer
> [8] https://groups.google.com/d/optout
> [9]
> https://groups.google.com/d/msgid/openpnp/CALsNZy19_uWjtw_KaqnPf5ZNfOCjyYq-1JqHfuTJSZ-Lc8U9RA%40mail.gmail.com?utm_medium=email&utm_source=footer

[Henrik Olsson]

Yes, when one nozzle goes down the other one goes up and since the weight
are the same on both sides it's sort of balanced reducing the load on the
motor.

Nope, can't take credit for that idea. I first saw it used on the SmallSMT
machines.

/Henrik.

-----Ursprungligt meddelande-----
Från: ope...@googlegroups.com [mailto:ope...@googlegroups.com] För matt
Skickat: den 25 maj 2016 21:38

Till: ope...@googlegroups.com
Ämne: Re: [OpenPnP] Re: Henriks machine, general presentation.

[Anthony Webb]

Peter used similar in his head design.  I'm excited to see them in action!

--
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/8836F82EC78B477A9A847DE9E81154D9%40Office.

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

[matt]

How well does this head design work in practise? Any videos?

Thanks

Matt

>> [1].
>>
>> For more options, visit https://groups.google.com/d/optout [2].

>
> --
> 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/CALsNZy33HRo2gOJ9Cgz9PkWCUpFjuszODohE_Usu9HWPogOrVA%40mail.gmail.com
> [3].
> For more options, visit https://groups.google.com/d/optout [2].
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/openpnp/8836F82EC78B477A9A847DE9E81154D9%40Office
> [2] https://groups.google.com/d/optout
> [3]
> https://groups.google.com/d/msgid/openpnp/CALsNZy33HRo2gOJ9Cgz9PkWCUpFjuszODohE_Usu9HWPogOrVA%40mail.gmail.com?utm_medium=email&utm_source=footer

[Henrik Olsson]

If you mean the design principle just search for SmallSMT on Youtube and
have a look. Here's one example where they're changing nozzles as well:
https://www.youtube.com/watch?v=5NNG4zVMPWg

If you mean my version of the design then I don't know yet. Haven't powered
it up yet....

/Henrik.

-----Ursprungligt meddelande-----
Från: ope...@googlegroups.com [mailto:ope...@googlegroups.com] För matt

Skickat: den 25 maj 2016 22:18
Till: ope...@googlegroups.com
Kopia: Anthony Webb

Ämne: Re: [OpenPnP] Re: Henriks machine, general presentation.

[Andrew Frazer]

Why did you put a mirror in the bottom camera setup..  is it just because of space. 

[Jason von Nieda]

Hi Henrik,

Things are looking very good! Congratulations on your progress!

I ran your images though the bottom vision pipeline, and it looks like you'll have no problems:

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 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/4eac75ed-d079-4d33-94c3-9749b5cabb06%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Henrik Olsson]

Andrew,

Yes. The TM6 camera with its 35mm lens and connectors sticking out at the back is roughly 150mm long, I don't have that much space available vertically.

/Henrik.

[Glen English]

I vote for modbus or CAN.
cheap and easy MCU implementation.

or even I2C (no extra hardware for the MCU except for two resistors and optionally some tiny TVS)

 

[Henrik Olsson]

Glen,

On the hardware side it's RS485 for ME because that's how the hardware is designed. As for the actual protocol MODBUS is an option but, as has been previously discussed, it's really more complicated than it needs to be and requires more "support" on the PC side than what's currently there with the sub-driver concept.

I2C, nah. I'd personally rather use SPI in that case but it gets "complicated" on the PC-side since it's no longer a simple COM-port which is easy to "get" and again, for me it's RS485 which I also believe is much better suited for the job than I2C or SPI.

CAN, sure, (I believe that's what the Neoden 4 feeders are using). Still need some sort of protocol "inside" though and it might not "fit" very well with the sub-driver concept Jason has now.

I'm not a Java programmer so I'll have to rely on what tools Jason provides us with and I think that the subdriver concept with simple ASCII based string output sounds perfect. Easy to understand, easy to debug. YMMV of course.

/Henrik.

[Michael Anton]

I agree completely.  This has been discussed repeatedly, and the only two interfaces really suitable for this sort of thing are RS485, and CAN.  The others were just never meant to be used with long cables in a noisy environment.  Maybe they can be made to work, but the question is why, when there are others far more suitable.  Good engineering starts with using the appropriate tool for the job.

As far as the protocol on the wire, I always favor the simplest one.  MODBUS really is pretty complicated, and offers little over a simpler protocol for this application.  Personally I'd only use MODBUS if the device was required to communicate with something else that uses it.  I've used it in the past, and really didn't care for it, and a proper implementation is really quite complicated.

To me it seems like you are on the right path Henrik, so keep at it.  When I complete my feeder design, it too will use RS485.

Mike

[Andrew Frazer]

Ethernet and Profinet for me.

[Henrik]

Hi,

First of all a big thank you to Jason (should have said that earlier) for running my images thru the pipeline, it does indeed look promising, I'll stick with that camera but I might back it off a Little bit to get a wider field of view since even the 0603 seems to work fine.

As for the various protocols and electrical interfaces for feeders etc I look forward to see anything and everything others come up with but I've got my mind (and actual hardware) set on RS485. As for the protocol it'll be what the sub-driver concept allows - simple as that.

The head mount PCB's have left the factory but will obviously take a while to get here, Then we'll see how much I goofed up.... I'll share a rendering of it for now.

There's a breakaway section at the top to which the pressure sensors will be mounted. This will then sit slightly above the main board in order to gain access to the port(s) on the sensors. The cables for the nozzle motors will be routed up and past this board, then turn back down again under the small daughter board and be cable-tied to the main PCB at the entry Point of the screw terminal(s).

All wiring from the main controller comes in at the top and, as decribed earlier, the board simply redistributes the Z-limit, Z-motor, nozzle motors and video signals. Yes I'll be using SMA connectors  for video which may not be ideal due to its 50ohm nature (ideally it should be 75ohm for video) but considering that the capture device is using audio cable and cinch connectors I don't think it'll make much difference.....

/Henrik.

[Glen English]

Nice work Hendrik on the PCB !

I'd accept ASCII control  if :

1) it is properly escaped and char stuffed.

2) there is a decent CRC (not a checksum ). just use ethernet 32 bit crc, everyone knows how it works.

I guess it becomes a bit  like modbus ASCII instead of modbus RTU...

I think handling asynchronous events is no big deal. I know Jason can handle those no problem. just means a few more threads but in the end easier code.

[Mark Harris]

You can get 75 ohm SMA and 75ohm coax connectors if you want to keep things with the correct impedance :)

--
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/472cdc36-8771-4c82-ae8f-6bf8b3db0f2c%40googlegroups.com.

[Glen English]

SMPTE 272M application...

[Henrik]

Finally got the new head connected for some initial tests. Motion is nice, smooth and, I think, fast enough. I've uploaded a clip here:

https://youtu.be/4Igw5ot29vY

For this test motion was from Mach3 since I still have all that connected. Will soon start rewiring everything for Smoothie and OpenPnP. 

/Henrik.

[Jason von Nieda]

Whoa... that's FAST! Nice work Henrik! If that's the kind of speed you are going for I can't wait to see what your XY does! :)

Congratulations on getting things moving!

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 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/b39a690f-577b-4728-9e90-e913cca4f1c7%40googlegroups.com.

[mojalovaa1]

Very nice , what you are use for actuator?

[Henrik]

Thanks Jason,

 

I didn’t shoot for anything in particular with the Z-axis speed – except ”not slow”. I think I managed that.

The acceleration is 2.2G, I wonder if the part will fall off the nozzle….

 

Unfortunately X/Y, being on ballscrews, is not nearly as fast. Currently they’re set to 15m/min (and 0.1G acceleration) but will theoretically do 20 if pushed to the max. I’m shopping around for 20mm pitch screws in order to double that speed but at the moment I need (really trying to convince myself) to focus on getting what I have working instead of the endless “upgrade loop” I’ve seemed to put myself in J

 

I really want to get the machine moving under OpenPnP so I can start playing with the subdriver and getting my feeders to work but in order to do that I need to move the electronics to a larger cabinet where the Smoothie and some other stuff will fit and that will bring on more “small things I need to do”….

BTW, the updated docs are great, thanks for doing that (too)!

Oh, here's photo of (one side of) a PCB-holder that I machined, it's got a bunch of pockets for various size ICs like SO8-SO28, TQFP44, SOT223 etc. (Another idea I borrowed from SmallSMT but their probably not the first ones to do it either).

Bottom camera and mirror moved to its final location and tweaked (camera tilt and mirror rotation), think I've got it right:

And work surface (still with protective sheet on) with the finished "lightwell" for the bottom camera:

/Henrik.

[Henrik Olsson]

Hi,

If you mean driver for the stepper motor then it’s a 2M982.

If that’s not what you’re asking please elaborate and I’ll do my best to answer.

 

/Henrik.

 

---

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
To unsubscribe from this group and all its topics, 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/13a55817-69dc-4d84-8c20-6f575d9c96a9%40googlegroups.com.

[mojalovaa1]

Henrik , I m think  on the actuator needle for drag tape .

[Henrik Olsson]

Ah, I’ll not be using that. I initially started with the intention of using dragfeeding, you can see of video of it here: https://www.youtube.com/watch?v=aOxhEA7rVYg  but I never came to terms with it how to handle the cover tape and the possibility of the pick position drifting so for the common parts I’ll be using the motorized feeders you see in the beginning of the thread, then I’ll be using various trays and strips. At least that’s the plan.

 

/Henrik.

 

---

--

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
To unsubscribe from this group and all its topics, 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/ef4dfdb9-d164-41a1-800a-c59293c1ae03%40googlegroups.com.

[mojalovaa1]

I see that you not have cover puller , but for me is interested what you are use for actuator , that is pneumatic or electromagnetic actuator ?
About automatic feeder , that is not cheap options , I m plane design some cheap feeder but on other side need be 100% precise for use  , before  I m use this feeder : https://www.youtube.com/watch?v=4fr3bUYexXc  , then after I m make drag feeder  but on this moment I think that I will design something new  for my new machine .

[Henrik Olsson]

It was a small BOSCH pneumatic cylinder.

Automatic feeders aren’t the cheapest option for sure. But now there are the Yamaha feeders on AliExpress which I think is reasonably priced and apparently you can cut deals with the seller(s) when buying multiple – which you would do. Still going to cost a fair bit of change of course.

 

/Henrik.

 

---

Från: ope...@googlegroups.com [mailto:ope...@googlegroups.com] För mojalovaa1
Skickat: den 19 juni 2016 21:56
Till: OpenPnP
Ämne: Re: [OpenPnP] Re: Henriks machine, general presentation.

 

I see that you not have cover puller , but for me is interested what you are use for actuator , that is pneumatic or electromagnetic actuator ?

About automatic feeder , that is not cheap options , I m plane design some cheap feeder but on other side need be 100% precise for use  , before  I m use this feeder : https://www.youtube.com/watch?v=4fr3bUYexXc  , then after I m make drag feeder  but on this moment I think that I will design something new  for my new machine .

--

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
To unsubscribe from this group and all its topics, 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/256c5806-d596-44a2-a3d4-a544e80c4445%40googlegroups.com.

[mojalovaa1]

I m buy now this stepper driver  for x and y axis , I hope so that will be ok : http://www.ebay.com/itm/191539127624?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

[Mark Harris]

Buy the genuine DM542, not the chinese knockoff:

http://www.omc-stepperonline.com/leadshine-dm542-digital-stepper-driver-2050-vdc-with-1042a-p-77.html

Its twice the price, but worth spending the extra money on :)

On 19 June 2016 at 17:01, mojalovaa1 <moja...@gmail.com> wrote:

I m buy now this stepper driver  for x and y axis , I hope so that will be ok : http://www.ebay.com/itm/191539127624?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

--

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/1bd98be8-02f7-4c73-b2b6-70ca460efec4%40googlegroups.com.

[Cri S]

I don't think that for the motors hi have selected, the china clone or
the orginal make difference. The motor require 75V and 6A drivers
having high inertia and is made for cnc type app, higher
holding force, high rotational inertia mass, lower speed and high weight.

2016-06-20 0:16 GMT, Mark Harris <ma...@rris.com.au>:

> Buy the genuine DM542, not the chinese knockoff:
> http://www.omc-stepperonline.com/leadshine-dm542-digital-stepper-driver-2050-vdc-with-1042a-p-77.html
>
> Its twice the price, but worth spending the extra money on :)
>

> On 19 June 2016 at 17:01, mojalovaa1 <moja...@gmail.com> wrote:
>
>> I m buy now this stepper driver for x and y axis , I hope so that will
>> be
>> ok :
>> http://www.ebay.com/itm/191539127624?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
>>
>> --
>> 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/1bd98be8-02f7-4c73-b2b6-70ca460efec4%40googlegroups.com

>> <https://groups.google.com/d/msgid/openpnp/1bd98be8-02f7-4c73-b2b6-70ca460efec4%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 a topic in the
> Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAJMBTyS9WxrYos_c4eWYP2U%2BRW3Kd4TgPx7AM1poN5OUXFOp8w%40mail.gmail.com.

[Михаил Юров]

These are different drivers.

Leadshine DM542 - digital driver with a DSP processor.

On ebay - not leadshine. There's the cheapest clone leadhime M542 model.

For example (real Leadshine):

http://ru.aliexpress.com/item/Freeshipping-DM542-Leadshine-2-phase-digital-stepper-drive-20-50DCV-1-0-4-2A-2-128/1756347753.html?spm=2114.30010708.3.1.lNVsTY&ws_ab_test=searchweb201556_0,searchweb201602_3_10039_10048_10017_10046_10045_10040,searchweb201603_10&btsid=2f32c66e-de4f-4b09-be08-1c4a2559c4ca

[Henrik]

Hi guys,

Just thought I'd do an update as I'm getting really close to actually moving the machine using the Smoothie and OpenPnP for the first time. Will probably try out Pronterface or "manually" sending it some G-code from a terminal while trying to figure out all the Smoothie settings Before I get to OpenPnP.

What I've got left to do primarily is to hook up the solenoid valves, vacuum pump and sensors and some wiring for the feeders. The new control cabinet is not 100% finished yet (will it ever be?) but getting there. I've got more room in this than in the previous box but not enough to do a proper job with conduits etc so it looks a bit more messy then I'd like but whatever.... All drives and motors hooked up, no smoke, and the current loop of DM432C drives for the nozzle motors have been tuned, the motors turn super duper smooth at 36000 steps/rev.

Anyway, I'll likely be back asking for some help with the G-code driver and subdriver for the feeders (and possibly some Smoothie specific questions as well) in the not so distant future. In the meantime, here are a couple of photos of the machine as of today:

[Anthony Webb]

Really beautiful machine!! Can't wait to see her in action!

Sent from my iPhone

--

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/be3dcd13-c17f-4b47-96ec-65cd758782a9%40googlegroups.com.

[Arthur Wolf]

Hey.

I just wanted to say that wiring looks really really neat.

Do you have those pictures in even better res ? If so, I wouldn't mind getting my hand on them so I can post this to all smoothie-related media.
People are quite often looking for examples of wiring.

Cheers :)

--

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/be3dcd13-c17f-4b47-96ec-65cd758782a9%40googlegroups.com.

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

--

Courage et bonne humeur.

[Jason von Nieda]

Stunning work Henrik. Really beautiful! Looking forward to seeing it go!

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 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/be3dcd13-c17f-4b47-96ec-65cd758782a9%40googlegroups.com.

[Henrik]

Thanks guys!

OK, first question:

I have my two cameras connected thru EasyCAP USB capture devices (two different models apparently). Using Amcap (3rd party capture software) I can see and switch between the two cameras without any problems.

In OpenPnP, on the Cameras tab, I add a new camera, select USB Webcam and at the bottom of the Camera Specific tab there's a drop down selection showing my two EasyCAP devices.

If I leave it at the already selected item "all" that's happening is that I get no video, if I try to select the other device in the drop down list OpenPnP hangs as soon as I click [Apply] and a BSOD follows within a couple of seconds. At no time have I been able to get the video into OpenPnP (yes, I've selected the camera in the dropdown list above the video window).

Restarting OpenPnP, get into Cameras tab, selecting the previously created camera and pressing delete - BSOD again.

 

Running Window7 64bit, OpenPnp build 9deb48. What am I doing wrong? Should I select something other than Webcam?

TIA

   /Henrik.

[Jason von Nieda]

Henrik, I suggest using the opencvcamera. I am mobile at the moment but can help more later. Note that you'll need to pick the deviceid on the camera config. It should be 0 and 1 for the two cams.

Also, check out the setup and calibration guide on the wiki.

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 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/5bc21831-d9c9-4ffa-aca9-eacbd3054c89%40googlegroups.com.

[Henrik Olsson]

Thanks Jason,

Selecting the OpenCV camera instead allowed me to get the headmounted camera going (Device ID 0) but as soon as I add the second one, setting it’s device ID to 1 and clicking [Apply] the feed for the first one freezes and I get nothing from the second (I’m guessing everything video related freezes).

 

Exiting OpenPnP at this point results in another BSOD, I’ve seen more of those today than I’ve had in the last 10 years J.

 

I’ve also tried, with only one OpenCvCamera setting, its Device ID to 1 in order to THEN add the next one with device ID 0 but as soon as I change the DeviceID and click [Apply] it crashes.

 

Copy pasting the <camera></camera> block in machine.xml, changing name, device index and the identifier string now results OpenPnP not starting. It does show up under processes in the task manager (using 600MB of memory) but no application on screen. Usually when I mess up the config it tells me it’s corrupt but not here.

 

I wanted to get video up and running so I could to do final alignment under power but this has now taken all day and part from ordering new capture devices and/or reinstalling Windows as per the old ’98 days I don’t know what to do.

 

Thanks!

 

   /Henrik.

 

 

 

---

Från: ope...@googlegroups.com [mailto:ope...@googlegroups.com] För Jason von Nieda
Skickat: den 17 juli 2016 19:57
Till: OpenPnP
Ämne: Re: [OpenPnP] Re: Henriks machine, general presentation.

 

Henrik, I suggest using the opencvcamera. I am mobile at the moment but can help more later. Note that you'll need to pick the deviceid on the camera config. It should be 0 and 1 for the two cams.

Also, check out the setup and calibration guide on the wiki.

Jason

.

[Jason von Nieda]

Henrik, are you able to show both cameras at the same time using another program? It could be that the ezcap Windows driver doesn't handle multiple devices simultaneously.

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 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/39B7C5EECE1E41F898534985C1BEE62C%40Office.

[Jason von Nieda]

Another thing to try: make sure each capture device is on its own USB port, instead of a hub.

[Cri S]

Install virtualdup and check if that works.
Check the opencv driver number and change I'd accordly. Don't know if that works on unmodified driver, presumably yes, but every opencv program should work. If wvm works, javafcm webcam could use that driver, but opencv can access it too, if its compiled in.

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
To unsubscribe from this group and all its topics, 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/CA%2BQw0jx0z8q2VXLO-GZSKkNMAMH7wFhgM-ohPW4oreh4Pwj7%3DQ%40mail.gmail.com.

[Henrik Olsson]

Hmmm, don’t know.

The Amcap application only allows me to select one or the other – which is what I’ve been trying in OpenPnP but perhaps it’s actually accessing both streams even if it’s not displaying them? Tried running two instances of Amcap but that didn’t work.

 

Downloaded VirtualDub, didn’t find an obvious way to show two streams at once so tried running two instances but as with Amcap only the stream selected in the first instance was working.

 

The capture devices are connected directly to the computer, no (external) hub.

 

So, these devices are unusable then – great.

Anyone know of something that actually works for what we’re doing here? I don’t care if they’re $100 each, I’m sick of messing around with crap but I suspect it’s either the $10 crap or $1000 pro gear which then isn’t DirectShow compatible and yadda yadda yadda.

 

The alternative is to do as SmallSMT are doing and using one capture device and switching the cameras in/out using relays (or solid state switches or whatever) but that’s yet another project and would need support from within OpenPnP….

 

/Henrik.

 

 

---

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
To unsubscribe from this group and all its topics, 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/CA%2BQw0jxqVZjNf62d4CMfDW9x3Pf%2B%3D%2B%3DFstBH8%2BiE%3D8W33bMtWw%40mail.gmail.com.

[Cri S]

Now try open the second camera with VFW. And check if camera is switching correctly. Two cam require two digitalizer if required at same time.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/AD9E4CFEBF9643DEA139FCA5F4C31F1E%40Office.

[Henrik Olsson]

VFW? Video For Windows? Seems to be some sort of (old, superseeded) development framework (I’m not a software developer) so I don’t really know what I’m supposed to do with it. If that’s not it, please enlighten me.

 

But I tried running one instance of VirtualDub and one instance of Amcap and accessing one camera from each – no go so I’m probably dead in the water L

 

/Henrik.

 

---

Från: ope...@googlegroups.com [mailto:ope...@googlegroups.com] För Cri S
Skickat: den 17 juli 2016 22:35
Till: ope...@googlegroups.com
Ämne: Re: SV: [OpenPnP] Re: Henriks machine, general presentation.

[Cri S]

The problem is, this devices have one digitalizer and one MUX that must be programmed.
On newer code these MUX are depredicated, so higher end video card need VFW drivers for accessing the MUX directly.
I have asked virtualdup to know that you have installed the VFW drivers. On default no drivers is installed on win7, some video card or gaming /DVD software install it.
The hope is to use different api and that there reprogram the MUX, when switching between cams. But for that you need the list of opencv driver ports and set that number manually on opencv, because VFW is a low number and opencv use that ad default. Probably webcam is better as default. Test one cam  using old VFW and the other using webcam, but is probably same as opencv and webcam at same time.
These devices are cheap. The solution is to open only the first cam and reprogramming the MUX, its a special code send with opencv but 99.999% not supported on java. If webcam and VFW works, OK otherwise buiy10$ webcam or USB video digitalizer.

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
To unsubscribe from this group and all its topics, 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/749D80E0F47F4D5285CA236563C1314D%40Office.

[Henrik Olsson]

Ah, now I see, you mean selecting VFW as the camera type in OpenPnP, I was in “outside of OpenPnP mode” - OK.

 

Unfortunately, adding a camera (be it the first or the second) of type VFW camera OpenPnP just exits as soon as I click on it in the camera lis. And, as before, selecting Webcamera simply hangs OpenPnP. The only way I can get video in OpenPnP is by selecting OpenCV camera and that only works as long as one and only one camera is defined.

 

I definitely don’t want to replace my industrial uplooking camera with a $10 webcam but the headmounted one actually isn’t that great so…. As for buying USB digitizers – that’s what I did, right, I just didn’t realize you couldn’t use more than one of them at the same time.

 

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJGcfUg%3DgiaV6TMtidfLrRhCtQ%3D3Uz7vEQG4Q2EKBJ%3DPbx9abQ%40mail.gmail.com.

[Cri S]

You definitely need to set the correct camera Id,  on Google I don't find the list, I'm sending it next time I power up the PC.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/49DE4481CE504983AF13DEAFF7F4F20C%40Office.

[Henrik Olsson]

Thanks for all the help! You apparently know a lot of things about this stuff that I don’t and I’m not always following, unfortunately.

 

If you mean setting the camera ID in OpenPnP it’s when I do that that it crashes (for OpenCVCamera which is the only type I’ve been able to get ANY video thru). If you mean setting an ID when choosing VFW camera in OpenPnP then it won’t let me because as soon as I click the newly added camera in the list (in order to get to its settings on the right hand side) OpenPnP just plain exits. And when I select Webcam it crashes as soon as I try changing the “device” in the camera settings.

 

I think we’re all on the same page here but just so there are no misunderstandings. I’m using two cameras with composite video output, each feeding into its own USB capture device, each connected to it’s own USB-port. Two cameras, two capture devices. They look the same but they aren’t even using the same drivers and they show up under different nodes in the device manager. I’ll crack them open and see what chips they’re using.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJGcfUigMm5_wo0zEm%3Dpk8POUhHC1_3%2B-OFOnciTy4E59nRhUw%40mail.gmail.com.

[Cri S]

For openpnp, select one camera on opencv, close openpnp, save copy of  machine.XML . now delete camera on machine.XML.
Configure the other camera on webcam. Close openpnp.
Now copy and paste the saved camera configuration of backup openpnp camera to the machine.XML file.
Test it. Eventually invert id or camera.

[Cri S]

I was supposing you use one capturing device with two analog cameras.
If you use two USB capturing devices, first thing to try is not using VFW driver. Need to check if that is possible on openpnp.
Actually I'm busy , give me 20 min and I can check it.

[Henrik Olsson]

No, two cameras, two capture devices.

And again:

The only way I’ve ever been able to get video in OpenPnP is to select OpenCV camera, as Jason suggested, but it ONLY allows me to have ONE – not both.

Webcamera, no video, crash and BSOD when trying to select WHICH of the two devices to use.

VFWCamera, no video, instant exit as soon as the camera is selected in the list.

 

Will have to call it quits for today L

 

 

---

Från: ope...@googlegroups.com [mailto:ope...@googlegroups.com] För Cri S
Skickat: den 17 juli 2016 23:57
Till: ope...@googlegroups.com
Ämne: Re: SV: [OpenPnP] Re: Henriks machine, general presentation.

 

I was supposing you use one capturing device with two analog cameras.

[Cri S]

ok, videodup have proved that you have VFW installed.
OpenPnP works settings camera id on machine.xml until you open the
config wizard.

OpenCV use that , maybe, or it use MIL , lower numbers win.
-1 = first camera found
0-99 = first 100 cameras from all drivers found, if some interface
access the same
camera, lower number wins.
Range for camera id relevant for Windows without special 3th part driver.
100 - 199 = MIL
200 - 299 = VFW
500 - 599 = QT
700 - 799 = DS
1400-1499= MMF



2016-07-17 22:06 GMT, Henrik Olsson <hen...@henriksplace.se>:

> No, two cameras, two capture devices.
>
> And again:
>
> The only way I’ve ever been able to get video in OpenPnP is to select
> OpenCV
> camera, as Jason suggested, but it ONLY allows me to have ONE – not both.
>
> Webcamera, no video, crash and BSOD when trying to select WHICH of the two
> devices to use.
>
> VFWCamera, no video, instant exit as soon as the camera is selected in the
> list.
>
>
>

> Will have to call it quits for today :-(
>
>
>
>
>
> _____

>
> Från: ope...@googlegroups.com [mailto:ope...@googlegroups.com] För Cri S
> Skickat: den 17 juli 2016 23:57
> Till: ope...@googlegroups.com
> Ämne: Re: SV: [OpenPnP] Re: Henriks machine, general presentation.
>
>
>
> I was supposing you use one capturing device with two analog cameras.
> If you use two USB capturing devices, first thing to try is not using VFW
> driver. Need to check if that is possible on openpnp.
> Actually I'm busy , give me 20 min and I can check it.
>

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
> To unsubscribe from this group and all its topics, 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/C4CE7BDBE0E147048447244C0A390446%40Office.

[Jason von Nieda]

Henrik,

OpenCvCamera is the most stable camera interface we've got right now, and we're still at the mercy of OpenCV. That being said, once you get a configuration that works it should be rock solid. The most error prone part of the process is getting the right IDs and connections.

The VfwCamera is very out of date and is really only left there in case some folks with old machines are still using it. It should probably just be removed. It only works on 32 bit machines. The WebcamCapture camera is a relatively new addition that uses a Java webcam library with access to many underlying capture systems but it has not received much testing and as you saw, it's not very stable.

The best thing to do, in my experience, is make sure you can access both cameras simultaneously with something other than OpenPnP. This rules out OpenPnP and OpenCV and lets you focus on making sure the cameras all work properly. I'd suggest what piece of software to use to do this if I could, but I work on Mac and don't know what to suggest for Windows. Any security camera monitoring software, or webcam capture software that can handle more than one camera should do the trick.

Once you have both working externally, it should just be a matter of adding two OpenCvCameras and set the first one to Device ID 0 and the second to 1. Or if you have an internal camera you may need to use 1 and 2. 

If you find you can't access both at once outside of OpenPnP then you won't be able to access both at once inside of OpenPnP. You may need to consider a different capture board. It may help to search for capture systems that are known to be compatible with OpenCV and if you do find you need different hardware, perhaps post here about what you are considering first to see if anyone has experience with it.

You've reached the frustrating part of the build, but hang in there. You have a completely custom machine and it will require some work to get it all configured, but you'll get there with patience :)

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 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/C4CE7BDBE0E147048447244C0A390446%40Office.

[Cri S]

Only one usb capture device can be on the one root usb hub.
check it out using http://www.nirsoft.net/utils/usbdeview.zip and
http://www.usbman.com/WebDrivers/USBview/USBVIEW.EXE
to be sure to connect it to different usb root hubs.
On some pc, there is only one root hub. in this case, additional usb
card is needed.
Below is python code that checks first camera, then second camera, and
then both.
27 ìs the ESC key, that advance the state. It loops until it get valid
image, if you
ask why two loops. Some cameras return some invalid frame until it works.
If second is is negative, no second camera is tested.


import cv2

id1 = -1
id2 = -2

###############################
## camera 1
###############################

cam1 = cv2.VideoCapture(id1)
cam1.set(5,30) # FPS
cam1.set(15, 0.1)

while(True):
ret,frame = cam1.read()
if ret:
break
cv2.waitKey(10)

while(True):
ret,frame = cam1.read()
if ret:
cv2.imshow('cam1', frame)
if (cv2.waitKey(1) & 0xFF == 27):
break

###############################
## camera 2
###############################

if id2>=0 :
cam2 = cv2.VideoCapture(id2)
cam2.set(5,30) # FPS
cam2.set(15, 0.1)

while(True):
ret,frame = cam2.read()
if ret:
break
cv2.waitKey(10)

while(True):
ret,frame = cam2.read()
if ret:
cv2.imshow('cam2', frame)
if (cv2.waitKey(1) & 0xFF == 27):
break

###############################
## camera 1 & 2
###############################

while(True):
ret1,frame1 = cam1.read()
ret2,frame2 = cam2.read()
if ret1:
cv2.imshow('cam1', frame1)
if ret2:
cv2.imshow('cam2', frame2)
if (cv2.waitKey(1) & 0xFF == 27):
break

###############################
## release
###############################

cam2.release()

cam1.release()
cv2.destroyAllWindows()





2016-07-17 22:32 GMT, Jason von Nieda <ja...@vonnieda.org>:

>> ------------------------------
>>
>> *Från:* ope...@googlegroups.com [mailto:ope...@googlegroups.com] *För
>> *Cri
>> S
>> *Skickat:* den 17 juli 2016 23:57
>>
>>
>> *Till:* ope...@googlegroups.com
>> *Ämne:* Re: SV: [OpenPnP] Re: Henriks machine, general presentation.

>>
>>
>>
>> I was supposing you use one capturing device with two analog cameras.
>>
>> If you use two USB capturing devices, first thing to try is not using VFW
>> driver. Need to check if that is possible on openpnp.
>> Actually I'm busy , give me 20 min and I can check it.
>>
>> --
>> 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/C4CE7BDBE0E147048447244C0A390446%40Office

>> <https://groups.google.com/d/msgid/openpnp/C4CE7BDBE0E147048447244C0A390446%40Office?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 a topic in the
> Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CA%2BQw0jxeQxEKo%3DY_%2BtVXdwYXYZ_iiUz6xSR03UXhCsC-sKTrbQ%40mail.gmail.com.

[Cri S]

Using Id 700 or 1400 uses newer type of camera access instead of the 16bit vfw selected when using 0 , same for 1 and 701 ...

[Henrik Olsson]

Jason,

Don’t worry, I’m not blaiming OpenPnP J

I realise the issue exists outside of OpenPnP as well but it is a bit frustrating that it hangs, exits and crashes so vilolently, that doesn’t happen with the other apps, so it takes a lot of time trying all the various things.

 

I was hoping someone already knew of a capture device that worked, either multiple ones of the same or a multi channel device. A cheap 4-channel board I’ve played with before (years ago) required the use of the software that came with it. No other software could access the videostreams, same thing with a “professional” USB-camera I bought (also for this project initially) – only worked with THEIR “inspection software” so I’m a bit weary

 

Here’s one I’ve found:

http://www.usbgear.com/computer_cable_details.cfm?sku=USBG-4EYE&cats=125&catid=614%2C125%2C182%2C175

 

It clearly has 4 separate channels and it says simultaneous access to all 4 but will you be able to access them without using their specific surveillance software? I don’t expect you to provide an answer for that (but hey, if you do know then…) J

 

Anyway, thanks again, I’ll keep pushing.

 

/Henrik.

 

 

---

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
To unsubscribe from this group and all its topics, 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/CA%2BQw0jxeQxEKo%3DY_%2BtVXdwYXYZ_iiUz6xSR03UXhCsC-sKTrbQ%40mail.gmail.com.

[Henrik]

Thank you Cri S, making progress (sort of) !

I moved one of the capture devices to a USB-jack on the front of the machine and I can now run two instances of Amcap and see both streams at the same time, each in its own instance of Amcap:

 

 

Unfortunately, I haven't been able to make it work in OpenPnP. It's the same issue as before. I add the first camera (OpenCV) it gets ID0, I can see the video in the window - great.

Now I add the second camera, by default it TOO gets ID0 and I have to change it to 1 in the drop down selection box but as soon as I click [Apply] it freezes, exiting OpenPnP results in an instant BSOD.

I then deleted the configuration, restarted OpenPnP, added the first camera using the GUI, then copy/paste/edited the machine.xml to add the second one. Changed the ID string, Name, Looking and the Device-ID of the second camera. This time OpenPnP started properly and video from first camera still works but I got no video on the second camera. Exiting OpenPnP resulted in another BSOD. I'm attaching my machine.xml with ONE working camera. 

/Henrik. 

[mojalovaa1]

Cri.s if you remember similar problems is be on my computer  because all USB is work on one  router  , I m add some USB card  in machine and connect second camera  to that usb , after  that all is work .

Maybe this will help to you Henrik .

[Henrik Olsson]

Perhaps, but at this point I can see both streams, at the same time, outside of OpenPnP so it ”should” work inside OpenPnP as well.

If all else fail I’ll add a USB card but at this point I’m leaning MORE towards replacing one (or both) of the capture devices, I just don’t know with what.

 

/Henrik.

 

---

Från: ope...@googlegroups.com [mailto:ope...@googlegroups.com] För mojalovaa1
Skickat: den 18 juli 2016 11:55
Till: OpenPnP
Ämne: Re: [OpenPnP] Re: Henriks machine, general presentation.

 

Cri.s if you remember similar problems is be on my computer  because all USB is work on one  router  , I m add some USB card  in machine and connect second camera  to that usb , after  that all is work .

Maybe this will help to you Henrik .

--

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/E8rF2faOjAg/unsubscribe.
To unsubscribe from this group and all its topics, 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/af278e81-9b99-4fd9-b71a-2606721cc11c%40googlegroups.com.

[matt]

Do i need to do anything to implement safe-z support? I want to make
sure the head is back at Z0 before any X,Y movement takes place.
Obviously I can implement this in the firmware, but I wasn't sure if
OpenPNP already supports this, I keep seeing mention of "SafeZ" and
moveToSafeZ() seems to be implemented, but wasn't sure if this does what
I want - do i just need to define safeZ to be 0 - and before any
gotoXY() type calls, if z is not 0 - then it will automatically called
moveToSafeZ(0)?

Thanks in advance

Matt

[Cri S]

You should check the USB root hub issue with the indicated program. Anycap is customized
and i have seen many anycap that have additional capability
Not available outside anycap.
Further you should check 700 and 1400 drivers. 700 and 701 ...
1400 1401, not 0 and 1.
The machine.XML reveal you have enabled lens correction without doing calibration. This could be blue screen reason itself. Change camera I'd to 6 .
Add second camera and set camera I'd to 5.
Then close opencv and edit the I'd . if it works, fine, otherwise install Python and opencv 2.4.x .
Web is full of how to.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4FA69A3A5DFB4699917D55554AAF3C31%40Office.

[Henrik Olsson]

I have not enabled lens calibration, at least not intentionally but I’ll check that again. And if I’ve done it by mistake and it’s the cause of the BSOD then I’ve managed to enable it, by mistake, 20 times or so….

 

You keep saying drivers, what drivers? Are you saying I should try setting the device ID to 700/701 and 1400/1401 and 5/6 instead of 0/1 as per Jasons instructions.

 

I understand this is might be second nature to software developers which I’m not, I’m only a user. Have never touched Python but can follow instructions if they are written for the people that actually needs them.

 

Thanks again for you patience. I’ll keep messing with it as time permits.

 

/Henrik.

 

---

Från: ope...@googlegroups.com [mailto:ope...@googlegroups.com] För Cri S

Skickat: den 18 juli 2016 12:32
Till: ope...@googlegroups.com

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

[Cri S]

Device I'd 5/6 is for setting it to devices without real cameras in order it don't make blue screen and let you edit machine.XML manually after closing opencv having then two configured cameras.
Opencv access cameras using drivers. There are organized on 100 blocks. Driver 200 and 201 access VfW. 0-99 is just codes that check all driver and the first that works is returned.
If you open 1, first 101 is checked, then 201, 301 ...
And you have installed VFW drivers, otherwise virtualdup don't work.
700 and 1400 driver require videolib library. I don't know if it's compiled in on openpnp opencv. Because this is possible that it don't work on openpnp and outside yes.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/733959F01EE44B8C827BD91D07331E47%40Office.