Hello Guest it is January 15, 2021, 09:39:56 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - EngelenH

Pages: 1
Mach4 Plugins / Re: XHC WB04 plugin
« on: September 14, 2019, 05:22:40 PM »
3 things.

1. I haven't developed in C++ in AGES, last was 18 years ago and all of that on *nix platforms. A plugin would mean having to not only pick up C++ (and for that alas I have not the time at the moment) and more importantly to go read up on all the idiosyncrasies of C++ on Windows. Another can of worms I am not all that eager to get into. I should point out that I have looked at the code for both forks of the XHCWB04 driver here and got frustrated in no time flat trying to wrap my head around 4 different versions of MFC, 3 different versions of C++ (14.x, 17.x and generic) dialect not to mention Unicode or non-unicode libraries. That was quite enough for me thanks. Been working in C# on windows for the last 8 years (after some other stuff) and as such it made sense to go with that. I don't think however Mach4 plugins can be C# based (correct me here if need be)
2. I am not at present willing to engage in a non-disclosure agreement. This has nothing to do with NFS, more with the fact that I am currently employed in a rather strict work environment when it comes to conflicts of interest. Normally there should be no issue in me signing such an agreement but at the same time due to factors (that again have nothing to do with NFS) I can not discuss I am not willing to risk it either.
3. Taking 1 and 2 in consideration I decided going the IPC route, which is openly documented in the Mach4 documentation and as far as I can see requires no NDA. (again, if I am wrong here, by all means feel free to correct me).

Mach4 Plugins / Re: XHC WB04 plugin
« on: September 14, 2019, 12:36:30 PM »
I am going out on a limb here and say probably not.

I also tried with the Shaeto version (see also earlier in this thread) and could not get that to work either with the version of pendant I have.

So long story short I am looking into writing a C# version of the standalone app that uses Mach4 IPC. Got about 50% of the IPC calls mapped, also managed to get really basic IO to the HID driver for the pendant working. But still have a loooooong ways to go before these 2 ends meet in the middle and I can read all the data from the pendant HID driver, map it to know what buttons were pressed on said pendant etc, and then convert that to the right Mach4 IPC calls to create 2 way communication (which come to think of it I have not tested yet, I can read the raw data from the pendant but have not yet tried to send it data such as the XYZ positions for the LCD on the pendant).

Odd that there seems to be so little support/existing work for all this.

Mach4 Plugins / Re: XHC WB04 plugin
« on: July 31, 2019, 09:29:58 AM »
 I have one of the too, the one with the blue/orange buttons (4 axis version).

Good news is in you diagnostic screen I can see it is actually receiving data/pulses from the device just fine ... I just assume it is getting different codes than those expected. Perhaps it would be possible to make those individual codes user configurable. Or even better have some configuration screen that allows you click a function known/supported by the plugin and then it records the code sent when the user presses the matching button on the remote.

This would ensure at least some flexibility moving forward. I ordered the HB04 myself from amazon, and got the whb04b-4 instead. Not complaining mind you (as that one costs way more :) it seems) but it adds a level of tricky to this whole silly mess.

Ordered this:

but got this:

Ah yes, just got one of these too...

Alas expected it to work with the shuttlepro plugin from artsoft (should have read forums).

Did anyone get this one to work ?

Actually there is an even better option ... But it is a little more work to implement (well, I guess if you are already talking about using diodes and transistors about the same).

Use an opto coupler (ako opto isolator), their purpose is to galvanically seperate two circuits that still need to 'talk' to one another.

Essentially (grossly oversimplified) it is a combo of a LED and Photodiode, the signalling side gets the LED and when the LED lights up the Photodiode will allow current to flow on the receiving side. Thus there needs not be a direct link between signalling and receiving side.

Typically a PC817 is used here.

Example schematic would be (this one is for connecting an inductive proximity sensor to an arduino, same idea, courtesy of a small 'local' electronics store I frequent) :

edit: should point out that there are some cheap ready made boards that are specifically designed for purposes like this that you can probably find on ebay, amazon etc.

Pages: 1