Pick & Place MachineTVM920

[anfang]

right. machine interface  done....
not bad for an RF/analog man I guess, I have to do computer crap every now and then.

even got the mapping of the front three green, red, yellow buttons

and the command to lock/ unlock the cals and NVM

I'll add into the driver program the ability to pull out ALL the (cal) values out at boot , just like the qihe program does. (48 ints)
I want to see if they vary much between machines and understand any variations

Damn, very impressive.

What type of cal data is stored in the NVM?

[glenenglish]

Someone was asking about this

they are stored in the C:\users\QiHe\Desktop\<machineSN> \  .par file

the .par files has the goods.

there is also some other stuff stored in the param.dat file at
c\Users\QiHe\Desktop\SucfaceMountTouch_EN_Belt_V1.24Beta4

Anfang, to answer your question- NVM ( I think- I am not 100% sure but >51%)  scale factors for various things. I dont completely know, looks like I don't really have to know, either.  I read them all out.  I am looking into some of them now . Most of the stuff on the QiHe GUI is not required by the hardware at all. just scale factors for the various axis.

As for the motherboard Atom performance . Yeah, I guess the thing is "Your mileage may vary" , and it depends on your own preferences.
I'd suggest putting a mini ITX with a I3-xxxx into it if you want a single package.
and the Chinese windows is a pain even when you set it to ENGLISH language and keyboard (or whatever language you prefer) .

HOMING
Homing :  in my travels in wireshark etc, and measuring things etc, I think the home function in the QIHe software may not be deterministic.

(we of course will have my shiny new home function....)
 
This will cause perhaps a 0.1mm error , maybe more on the homing.
Leading it to think that it is somewhere where it is not quite
What is the impact of this ?
Well the feeders are at entered locations... so if you are trying to pick up 0402s, this might matter, unless you do a machine fiducial (which I recommend) .IE so you KNOW where the feeders are  even if the 'home' location was miles off....

g

[anfang]

Hi Glen, I was the guy that had made a request on the file contents. I documented as much as I could in the attached xls file (delete the txt extension).

The PAR file holds the parameters I was looking for. These formats are kind of a mess. Some files use micrometers, others use mm. Some use comma delimited fields, others just one item per line. The fact that some use micrometers would suggest that perhaps those are suited for embedded in the controller along with cal data so that the embedded half only deals with ints.

The PAR file holds the system settings. If you assign a name to your feeder, however, It's not here. it's in the DAT file.

The DAT file holds the various names you assign, and and the various feeder locations in micrometers. It's the exact same data as the PAR file. Just different format. No idea which takes precedence.

The QHD file is what is actually exported in the Edit->Export menu. It's fairly readable. But some parameters here really should be system settings. Things like pick and place delay should be in system settings, not specific to a job.

And the biggest mystery of all is....in the SysConfig menu there is a big fat save button. When you push that, nothing gets written to files according to procmon. There are a few registry writes that are inconsequential. And yet, if you change something, save it, and then terminate the app, the setting somehow persists. Now, procmon doesn't tell you much about the UDP activity other than it happened.

I wonder if the act of pushing 'save' pushes the part of the Param.DAT file that is in micrometers down to the embedded controller.

For a while, I also thought things like camera location might be held in the controller so that you just tell it to go to the camera and it happens. But looking at your doc you posted, that doesn't seem to be the case.

Maybe you could look at whether or not any udp stuff of significance happens when you push the SysConfig->Save button

I hope the xls helps you on your discoveries. You are doing god's work here.

And amen on the machine fiducial. I have a Madell DP2006 machine and it uses a machine fiducial. I visually checked the accuracy of home while tracking down by errors that seemed to come and go, and though it might be 10% of my overall errors.

[anfang]

As for the motherboard Atom performance . Yeah, I guess the thing is "Your mileage may vary" , and it depends on your own preferences.

The day the QiHe app becomes not needed, I will do precisely this. Along with a big touch monitor. But I'd hate to swap motherboards and then find out the QiHi app was tied to the motherboard.

I think the up camera could also benefit from a really high quality camera. I've done a lot with Blackfly USB3 cameras and they are great cameras. Very fast response, great API. Lots of lenses. So, when the day comes for a new motherboard, it'll be USB 3 for me too.

[glenenglish]

HI Anfang,
The QiHe is certainly NOT tied to the motherboard.... I have done 100% of my testing via network, with the internal PC powered OFF.

agreed on the Point Grey cameras, however, the OpenPNP guys report very good results with rather basic cheap USB cameras... remember OpenPNP does all image lens correction etc. But certainly better camera useful. see my blogs at glenenglish.com (wordpress)

I have dual monitors on my QIHe, so I have the PC monitor and 2 x LCD video monitors on the machine with a 2 way video splitter.

As for the SAVE button,  I've seen it update file times, but not change any contents !

I will check if the SAVE writes to the controller...

cheers

[zszabo]

@Peter

Once attache the plates to the machine could you check please the plates stability ?
QiHe reported that 16mm is not a good size as the feeders are wobbling as You may see on attached video made by them.

Please check this too and report back.

Thank You !
Zoltan

[glenenglish]

Hi Zoltan

I have verified that the 16mm feeder thickness is perfect.....- for my new chinese Cl  feeders and for the genuine yamaha feeders CL and FV type.

and of course it has to be- t is not the same as the genuine machine.

Does anyone else here apart from Mr PacketHead  and myself have a genuine Yamaha ? No ? well then.

If they wobble it is because the feeders they are using have been damaged by trying to put them on 17.2mm plate......
and besides, the machine does not wobble so the feeders should not.

It is possible to stretch / bend the CL feeder linkage by trying to put them on the 17.2mm plate.....

[thommo]

Hi Zoltan,

I concur with Glen's findings on the Feeder plate thickness - 16.0mm is correct.

Of course .. with sufficient force, everything will move [wobble]. I saw the QiHe video as it was being produced [by them], via Skype, and I also saw the 'wobble' they referred to and initially panicked about. It turns out they we using an 'old and worn' feeder, which no doubt was probably the 'cause' of this issue in the first instance, and possibly became worn due to it being forced onto their thick feeder plates.


However, just for clarity, the feeders are NOT clamped as 'tightly' as ones which have been 'forced' to fit [by applying excessive pressure to the plastic clamping handle], however there is no necessity for them to be this tight in any event.

If your machine is mounted correctly onto a stable surface, then leveled and aligned, there will be no appreciable 'wobble' using the new 16.0mm feeder plates. If not, you'll surely have 'other' issues you'll need to deal with in any event.

Mine will be installed into the machine tomorrow if things go to plan.

PS: don't forget to place some silicon lubricant onto the feeder pin which is mated with the O-ring for the air feed!

Cheers - Pete

@Peter

Once attache the plates to the machine could you check please the plates stability ?
QiHe reported that 16mm is not a good size as the feeders are wobbling as You may see on attached video made by them.

Please check this too and report back.

Thank You !
Zoltan

[zszabo]

Hi Peter,

Strange as I told them exactly same "probably the 'cause' of this issue in the first instance, and possibly became worn due to it being forced onto their thick feeder plates.", but Daisy told that they used new feeders, same as mines. So this is why Im curious, how it really behaves. May be the 16mm is correct for original feeders, but may be the copies need some more. May be a 16.5 or something like that would be accepted by original feeders and could be good for copy market feeders too.

Sorry Im just thinking about, but lets wait your results.
Good luck !
Zoltan

[thommo]

Hi Zoltan,

I have tested the Feeder/Plate combination already. The results I reported are as a result of me placing feeders into the new Plates. Aside from which, the feeders have a Machined 'flat' in two places in their base as a datum and seat, which ensure the Feeder is aligned vertically.

If you simply measure the gap in a closed Feeder you will discover it is sub 16.0mm, which is where the clamping force comes from.

The Yamaha feeder have no tolerance for anything thicker than 16.0mm.

If you ever have an opportunity to purchase some second-hand, they will not fit a thicker feeder plate.

Cheers - Peter

Hi Peter,

Strange as I told them exactly same "probably the 'cause' of this issue in the first instance, and possibly became worn due to it being forced onto their thick feeder plates.", but Daisy told that they used new feeders, same as mines. So this is why Im curious, how it really behaves. May be the 16mm is correct for original feeders, but may be the copies need some more. May be a 16.5 or something like that would be accepted by original feeders and could be good for copy market feeders too.

Sorry Im just thinking about, but lets wait your results.
Good luck !
Zoltan

[glenenglish]

Zoltan if you study the CL feeders, the newer Yamaha ones and the newer chinese copies you will find that they ONLY fit  >16mm by deforming and stretching.

The mechanism deforms and bends and stretches > 16.5mm.  0.5mm is the limit of taking up the bearing and bushes freeruns.

that is not a satisfactory way to operate a machine or its parts.

[ar__systems]

As for the SAVE button,  I've seen it update file times, but not change any contents !

I will check if the SAVE writes to the controller...

On 802 all machine related parameters are saved in NV registers of the machine. I presume the same happens here.

[zszabo]

Thanks guys,

Yes, I have studied the feeders that I received an I saw that 16mm looks OK for feeders clamping, and I didnt forced my feeders (as QiHe recommended) onto the 17.2mm plates. Just they video makes me little confused showing wobbling. This makes me to think that 16.x would be better. May be 16.5mm is exagerated, but still good for starting as that still can be easily reduced if needed May be ending up at 16.2. This trials should be done by QiHe, not by any user.

Of course if 16.0mm is fine for any CL feeder than Im fine with it.

Hope that this will be finalized soon and QiHe can send my plates too, and with a month delay I can start playing with my machine.

Zoltan

[anfang]

I'd say about 1 in 8 of my feeders seat perfectly on the thicker plate. The other don't seat fully, but seat enough such that they don't pop free.

[thommo]

Guys,

I think we've done the Feeder Plate issue to death now.

If you like what you have already, then that's great.
If you're happy to force the Feeder to mount correctly, that's great too.
If you want to match the genuine Yamaha machine design, that dimension is a 16.0mm plate - if not ... well that's perfect.

There's not really any more to 'add'.

Merry Xmas to all

Cheers - Pete

[anfang]

glenenglish, I grabbed a UDP  conversation on my machine. There are some differences from yours. Makes me wonder if your PNP bridge app will just work on other machines as is. Unrelated, the controller knows the serial number of my machine. When the PC sends out the 010000000000... (line 12) the controller responded with my machine serial number.  The SN seemed to go one way only. That is, the PC never sent the SN down. Probably not significant.

if you'd like, I'd try your app and capture a log for you.

[anfang]

Tomorrow I will try the Atom in the TVM and report the detection time there.

the Atom in the TVM is about 1/4 the speed on the recognition as my 8 core 3.6 GHz desktop. So, the 320x240 recognizers takes about 29 mS

[glenenglish]

I have moved software decode etc specific OpenPNP development Q & A and discussion to this topic :

https://www.eevblog.com/forum/manufacture/openpnp_qihe_sw-and-hw/


I feel the decode and development stuff is getting quite niche

General, non specific development should stay in  this-> thread

user questions

interested people

etc etc

[glenenglish]

Control processing of the machine is now complete.


Note this image attached is a INTERFACE to Open PNP

It has 100% of the control facilities. So if you need to check the operation of the machine at the low level, it can be done.

OpenPNP supports the high level process.

UPDATED with correct image...

[mrpackethead]

Low cost Chinese hardware that reportably is pretty good + Open Source Software that is pretty good.

Sub $10k solution that supports proper feeders.. Wow. this really does change the playing field a lot.

[thommo]

CONFIRMATION

OK - so here's the scoop!

I've been fortunate enough to get hold of a Beta release of @glenenglish's TVM920 decoder App.

EVERYTHING he reports is fact and everything he reports works!

This is a real GAMECHANGER guys.

For what seems like at least a year now, I've been reading blogs and discussions about releasing the benefit of good quality Chinese PnP machines which incorporate industry-standard Yamaha feeders, and coupling them at an application level [over which we have individual control if required] to our own software and workflow. In this instance, that application happens to be Jason's OpenPnP project.

Glen has confirmed that he'll have a 'complete interface' into the OpenPnP architecture ready in the next few days, and based on his track record so far, I've no reason not to believe it!

So I'd encourage all of you who either already own a TVM920, or are contemplating buying one in the near future, to support this effort and get on-board!

It appears obvious to me that [at least initially] that the more uses of a single machine type [eg TVM920] we all get participating early, the further this is likely to travel, and quickly.

Please spread the word to your colleagues and friends on this, and other blogs, or by whatever means you have.

For all those contemplating the journey into PnP, this is now a very PRACTICAL reality.

Glen - thanks so very much for this tremendous effort ... and of course to Jason for all that he and his contributors have created to date in their OpenPnP platform!

Cheers - Peter

[dtf]

Can't wait to try it!

[glenenglish]

OpenPNP operation of the TVM920  now in alpha test.

[thommo]

What did I say?

"Glen has confirmed that he'll have a 'complete interface' into the OpenPnP architecture ready in the next few days, and based on his track record so far, I've no reason not to believe it!"

OpenPNP operation of the TVM920  now in alpha test.

[harry4516]

keep calm thommo,
its a very long way to get a usable pnp software,
This is just the very first beginning.