OpenPNP_QiHe_SW and HW

[glenenglish]

This thread is for specific discussions, in this case, at least at the start , OpenPNP QiHe machines

for the purposes of developing, improving etc the 3rd party machine interface

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

Yeah the command 01 is a read and 02 is a write...
I will put up all the current files
and generate a release tonight for people to experiment with

UPDATED

Today I put in a question about one command, we will see if they reply !

Anfang, the only real mystery right now is these little gems
0.009 PCsend 8
0000   17 00 00 00 10 00 00 00                          ........
machine respond (2)
Data: 1700

0.0237 PC send 12
0000   02 00 00 00 f5 01 00 00 00 00 00 00              ............
MR (2)
Data: 0200

0.0386 PC send (12)
0000   02 00 00 00 f6 01 00 00 00 00 00 00              ............
MR (2)
Data: 0200

these are sent at start
and are also sent during homing
I am thinking they are some sort of LOCK, or they ALLOW the machine to travel past the opto-interuptor end-stops.

I think :
02 00 00 00 f5 01 00 00 01 00 00 00
see the 01 in the #8 byte of this data write at $f5 (01) ?

this happens before homing an axis
f401, f501, f601. I suspect it permits past stop movement for Z,Y and X

attached- .h files I have generated.
and a tvm920def.h file I use in c++

and also the diary of mine for the protocol! in order that I did it...... so the last line is my latest work.....
qihe.txt

anyway, all will be figured out shortly, I have not spent any time for two days, maybe tonight I will get some more done between my job.... a good challenge, also to get in another programmer mind....

I will put a data dump into it tonight so that we can do a data dump of those readout data dwords.. (readout 00 to 0x2f at startup)

[glenenglish]

fixed some things , typed over something stopped working(TVM920_RW_WRITE_CMD_BYTE)

[glenenglish]

a build for test, lots doesnt work (motion stuff is right now in re write)

note the registers read out in the MEMO box

registers print out HEX (big endian), and DECIMAL  and UNSIGNED

a few parameters are obvious like 8,9, (home position etc )

I have not tried to tun this on the ATOM but apparently ROb says it will run (MUST turn off firewalls !!!! otherwise it can't talk )

I use separate PC and USB network adaptor, static 192.168.0.10.
you might need to status ARP
arp -s 192.168.0.8 02:00:00:00:00:00

all the status works 100%, control of solenoids and on off things fine
motion I am rewriting at the moment, so that is a bit funny.
double clicking in the memo box writes memo box to text file .
start using START, stop using STOP or close application (X)

There is a Win32 CONSOLE behind the windows GUI, you might need to move windows gui to see it with all the goings on.
the asterix is a status update (16mS).

. more tomorrow

estimated time of OpenPNP integration - ~ Christmas Day. 25/26/27. family time next few days.

I can only send this executable directly, not through the blog.... u can private message  or email me if u want it

[glenenglish]

Anfang, I can confirm that a  GUI SAVE does  parameter write to the qiHe
at the end of the parameter write there is 03 00 00 00
which I can guess is maybe WRITE NV

g

[glenenglish]

progress

all motion stuff working, all feeder and vac ops all working
clean.

ran phony job on qihe software and found a bucket more high speed commands, decoded those....

got the thing moving around at "100%". quite stable.

note the files up on this blog are out of date by a mile......

need to get this up on GITHUB

[anfang]

Wow, man, merry christmas to us all from Glen! Absolutely awesome work you've done!

[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 become a very PRACTICAL reality.

Glen - thanks so very much for this tremendous effort!

Cheers - Peter

[mrpackethead]

To make this a practical reality the source code needs to be published.   Otherwise you have just put another closed software element in the way.

I hope the intention is that this will be the case.