.dll / VB questions - hardware instances

This code:

Code:

---

For i = 0 To 1
            FoundFBv4 = FusionBrain_WinUSB.MainUSBClass.FindMyDevice(i, 4)
            If FoundFBv4 Then
                FBv4 = i
                holderv4 = True
            End If

            FoundFBv3 = FusionBrain_WinUSB.MainUSBClass.FindMyDevice(i, 3)
            If FoundFBv3 Then
                FBv3 = i
                holderv3 = True
            End If
        Next

---

is causing both FBs to be = the same "fusion index" if either is plugged in separately, they're found at i=0 & the program works. If both are plugged in, both the v3 and v4 are found at i=0 and the v4 brain works, but has intermittent outputs set (inputs don't seem to be affected) as the v3 code is evaluated & sent to the same hardware instance as the v4. the v3 brain registers nothing (in or out). Basically, to the .dll, both FBs are at index 0, but the v4 overrides the v3 and process the bitstream (in and out, both v3 and v4 streams).

is there another/better way to distinguish between the 2? Or a way to set the hardware instance? I'm guessing windows reads them as separate device types since one is v3 & one is v4, causing the hardware instance to be 0 on both. Would this happen with 2 v4s? or v3s?

It would be nice to have 20+ outputs for my project, i could get by with 16, but I bought 2 FBs for a reason. (I'm sure i could eventually find a use for another but this project is nearing max budget).

I have a similar question. I'm scoping out a project that would need 4 to six FB's. The MDX software doesn't give me some of the capabilities that I need. Is it possible to recognize multiple FB's with the .vb app?

Quote:

---

Originally Posted by BurgersForAll

I have a similar question. I'm scoping out a project that would need 4 to six FB's. The MDX software doesn't give me some of the capabilities that I need. Is it possible to recognize multiple FB's with the .vb app?

---

What capabilities?

Capabilities and expertise. I lack the expertise. I was able to do some simple things with MDX but I'm having trouble getting the logging not to produce huge files. Also I can't time things off the system clock. Couldn't figure out either how to take keyboard input. I am more comfortable programming with VB in that I'm not a programmer.

It may be possible for me to get my app going with MDX but the learning curve maybe too steep.

Quote:

---

Originally Posted by BurgersForAll

Capabilities and expertise. I lack the expertise. I was able to do some simple things with MDX but I'm having trouble getting the logging not to produce huge files. Also I can't time things off the system clock. Couldn't figure out either how to take keyboard input. I am more comfortable programming with VB in that I'm not a programmer.

It may be possible for me to get my app going with MDX but the learning curve maybe too steep.

---

96 outputs & 78 inputs? have fun wiring.

I'm not sure, but I don't think i would have the same problems with 2+ v4 Brains (I'll probably try it eventually, just haven't ordered another v4 yet). I bought a v3 during the turkey sale last year & a v4 when they were released. The drivers are different & when both are connected, they are listed in separate sections in device manager. I'm pretty sure that's WHY both returned instance 0 from the dll, but i have no clue how to work around it. (need to install C# & check out the dll, but i don't know C# at all). If the .dll could be easily straightened out for v3 & v4 great, otherwise, I'd rather see it further developed for the v4 (if needed for PWM). My guess is the latter makes more sense & I'm more than OK with that. The v4 is a step forward & worth the change IMO.

Quote:

---

Capabilities and expertise.

---

I'd add flexibility to that, although MDX is coming along. It's not inflexible but as said, the learning curve is steep. VB can pull info from more places and system time & events were listed (that's on the way in MDX).

2k1 - I don't think MDX is the right software for what I've been using the Brain for. For a carputer where a pretty interface is needed, Yes, but MDX forces me to mess with the graphical side of things & I suck at making things pretty. I hate photoshop, so forcing me to use it turns me off. :lol:
The VB .dll can really shine for us "function over form" guys. I have enough trouble poking through the logic programming that screwing up a GUI takes WAY too much trouble shooting. The VB controls are nice'n'easy.
I DO hope you continue developing MDX, however, as i can see some uses down the road. (Home automation)

I like how MDX has come about & the way things have been implemented. My issue is that it's almost another "language" that I (1) don't have time to learn & (2) get frustrated by lack of documentation when I hit a wall. As the function & documentation of MDX increase, so will my use (& your collection of my $). :peace:

I am actually working on a non-skinnable override command to MDX that will make it look like a standard windows application.

If you have suggestions on features you want implemented in this, let me know.

Any way you could confirm that the .dll works with 2+ v4 brains in the manner it's supposed to? That might save me some frustration later on down the road.

I'm trying to figure out what you mean by "looks like a standard windows program" Would that just be a different skin? Maybe I'm missing somthing in how you're "supposed" to use MDX & the configurator? I'd rather write the logic/code in VB than in XML (that whole language thing I mentioned above). I'm not asking you to reinvent the wheel - VB is easy enough that even I can do it & it works quickly and quietly in the background. Maybe if there was a better guide for the xml portion - theres a ton of VB help on the web. Much easier than bugging you every time i can't figure something out.
I think VB is better for my current applications because I don't really need a user interface, If I did, MDX would be a much better solution. 90% of what I'm using the Brain for is done without the user knowing what is goin on (me, and I wrote the damn thing :) ), and most of the other visual/interactive 10% isn't completely necessary (but makes it more flexible, I could probably hard code it & do the same things). If i ever get to using the brain for a CarPC or HTPC (both ideas exist, just havent decided to go all out yet - $), I WANT the graphical functionality of MDX (to match backgrounds to the front end(s) used). At that point, I'll force myself to learn the idiosyncrasies that MDX has.

Iamthehor,

Did you get your VB code to work with more than one FB. I have the same issue. I am about 20% into my project and have run out of analog inputs. Please let me know if you have had any more sucess. Thanks

I got it to work fine. Below is the code for accessing two brains. It hooks up in the order the fb's are installed. I'm using two v4's. I'll soon order more as my app will need three.



Public Sub FB_SendReceive() 'This sub is called from a Timer_Tick event, which runs at 10Hz.

TemperatureSetPoints()

'----First Fusion Brain (This is a v4 FB)---------------------------------------------------------------------
ByteArray(61) = 2 + KeepAliveBit

For i = 0 To 15 'set the outputs
If DigOut(i) = 0 Then
ByteArray(i * 2) = 0
Else
If DigPWM(i) = 127 Then
ByteArray(i * 2) = DigPWM(i) * 2 + 1
Else
ByteArray(i * 2) = DigPWM(i) * 2
End If
End If

ByteArray(i * 2 + 1) = 1 'Pulse Width Modulation Operation Mode
Next

If FusionBrain_WinUSB.MainUSBClass.SendAndReceiveViaI nterruptTransfers(ByteArray, 0, HardwareVersion) Then
For i = 0 To 12
'The data coming in from the analog inputs is 10 bits long, so it has to come in two bytes.
'The first byte contains 2 bits, which are the most significant bits.
'The second byte contains 8 bits, and they are the least significant bits.

AnalogIn(i) = (CInt(ByteArray(i * 2 + 32)) * 256) + CInt(ByteArray(i * 2 + 33)) 'Uses both bytes 0-1023 (10 bits)
If AnalogIn(i) > 1023 Then AnalogIn(i) = 1023
'Range of 0-1023, so divide by 1023 to get a percent, then multiply by 5 if you want to get volts.
'AnalogIn(i) = (totalin / 1023) * 5
Next
End If

'-------------Second Fusion Brain-------------------------------------------------------------------------------
ByteArray(61) = 2 + KeepAliveBit

For i = 0 To 15 'set the outputs
If DigOut(i + 16) = 0 Then
ByteArray(i * 2) = 0
Else
If DigPWM(i + 16) = 127 Then
ByteArray(i * 2) = DigPWM(i + 16) * 2 + 1
Else
ByteArray(i * 2) = DigPWM(i + 16) * 2
End If
End If

ByteArray(i * 2 + 1) = 1 'Pulse Width Modulation Operation Mode

Next

If FusionBrain_WinUSB.MainUSBClass.SendAndReceiveViaI nterruptTransfers(ByteArray, 1, HardwareVersion) Then

For i = 0 To 12
AnalogIn(i + 13) = (CInt(ByteArray(i * 2 + 32)) * 256) + CInt(ByteArray(i * 2 + 33)) 'Uses both bytes 0-1023 (10 bits)
If AnalogIn(i + 13) > 1023 Then AnalogIn(i + 13) = 1023
Next
End If

I've only tried v3 + v4 with no luck, sounds like burgersforall got it working with 2 v4s & I have no reason to believe that it wouldn't work with my multi-brain code (which was lost in a HD crash :( ). If someone wants to loan me an extra v4, I'll test & report back, probably won't buy another v4 for a while (unless they go on sale, I'm a sucker).

I think the problem I have is with the way windows & the .dll connect to & "locate" the v3 vs v4 - both list as hardware instance 0 (which is true, just not handled properly by the .dll, which was written before v4 was conceived IIRC)

BFA - since you said before that you will be using 4-6 brains, you might loop your send/receive function with i=hardware instance to make it scale to however many brains you have connected. I think you can use FindAllDevices & get the last instance connected, then you could also redim your DigOut array to match ( (i+1) *16 - 1 ) (all this should be done in the connect function)
Could save you a lot of copying code (I always screw something up when i do that)