OpenPNP_QiHe_SW and HW - Page 1
Forum section: electronics / general

author: glenenglish
author_rank: Frequent Contributor
timestamp: December 21, 2016, 07:04:47 am
content: This thread is for specific discussions, in this case, at least at the start , OpenPNP QiHe machinesfor the purposes of developing, improving etc the 3rd party machine interface

author: glenenglish
author_rank: Frequent Contributor
timestamp: December 21, 2016, 07:27:38 am
content: QuoteYeah the command 01 is a read and 02 is a write...I will put up all the current filesand generate a release tonight for people to experiment withUPDATEDToday I put in a question about one command, we will see if they reply !Anfang, the only real mystery right now is these little gems0.009 PCsend 80000 17 00 00 00 10 00 00 00 ........machine respond (2)Data: 17000.0237 PC send 120000 02 00 00 00 f5 01 00 00 00 00 00 00 ............MR (2)Data: 02000.0386 PC send (12)0000 02 00 00 00 f6 01 00 00 00 00 00 00 ............MR (2)Data: 0200these are sent at startand are also sent during homingI 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 00see the 01 in the #8 byte of this data write at $f5 (01) ?this happens before homing an axisf401, f501, f601. I suspect it permits past stop movement for Z,Y and Xattached- .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.txtanyway, 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)

author: glenenglish
author_rank: Frequent Contributor
timestamp: December 21, 2016, 09:05:54 am
content: fixed some things , typed over something stopped working(TVM920_RW_WRITE_CMD_BYTE)

author: glenenglish
author_rank: Frequent Contributor
timestamp: December 21, 2016, 10:05:18 am
content: a build for test, lots doesnt work (motion stuff is right now in re write)note the registers read out in the MEMO boxregisters print out HEX (big endian), and DECIMAL and UNSIGNEDa 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 ARParp -s 192.168.0.8 02:00:00:00:00:00all the status works 100%, control of solenoids and on off things finemotion 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 tomorrowestimated 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

author: glenenglish
author_rank: Frequent Contributor
timestamp: December 22, 2016, 05:40:04 am
content: Anfang, I can confirm that a GUI SAVE does parameter write to the qiHeat the end of the parameter write there is 03 00 00 00which I can guess is maybe WRITE NVg

author: glenenglish
author_rank: Frequent Contributor
timestamp: December 22, 2016, 11:20:56 am
content: progressall motion stuff working, all feeder and vac ops all workingclean.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

author: anfang
author_rank: Regular Contributor
timestamp: December 24, 2016, 09:42:19 am
content: Wow, man, merry christmas to us all from Glen! Absolutely awesome work you've done!

author: thommo
author_rank: Frequent Contributor
timestamp: December 26, 2016, 12:01:58 am
content: CONFIRMATIONOK - 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 realGAMECHANGERguys.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 beJason's OpenPnP project.Glen has confirmed that he'll have a 'complete interface' into theOpenPnParchitecture 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 aTVM920, 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

author: mrpackethead
author_rank: Super Contributor
timestamp: January 05, 2017, 06:19:52 pm
content: 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.