Multiple card programming and other Information required

Hi,

I found your product at a local store and guess it could be a replacement for the card we use currently in most projects.
Since we have quite a long practice with the comeptitors card all we read and see is (of course) compared to the other SW.

I browsed your documentation and forums a lot.
I found two things - it seems as if the is some problem with your HID driver an DX (some versions).
And you don’t support notifications (interrupts) - instead polling must be done.
So far so good.

But there are some questions left open.
I see there is a (parameterles) “CloseDevice”.

My assumption:
I have two cards. App1 opens card 1. App2 opens card 2.
If App1 one calls CloseDevice - only the communication to card 1 is stopped.
App2 can still interact with card 2.
Am I right?

In the manual of the 8055 I found that it has
2 Analog Outputs
2 PWM Outputs.

The 8061 has on PWD Output.

My confusion:
In the DLL Manual of the 8061 I found a function “OutputPWM”.
BUT I could not find such a function for the 8055.
Is there something missing in the documentation???

We found that some of the “old” DLLs are available as pascal source.
From that we learned that the handling is primarily done vie the HID interface.

Your competitors device comes with an object oriented interface capable of events and notifications.
Using your device would mean that we have to build our own infrastructure using your DLL.
Going through the HID interface would make the things a lot easier for us – is there a documentation about it available?
Of course we could (based on the DLL source) figure out what to do, and how to do it
– I guess the guys at k8055.info/?id=1 did this
but documentation would be much better.

A bit about our “situation”.
We build (beside other things) custom apllications where sometimes HW Support (like sensoring, signaling) is needed.
Currently we use a board which has 8 Dig in / 8 Dig out / 8 Analog in.
The positives (compared to your board):
++ Small form factor (about 1/3 of your 8055).
++ 8 Analog in - great for sensoring.
…depends on type of project if needed
++ Fully .NET OO interface with events.
++Available also for mobile devices (Pocket PC)!!!
The negatives:
– Analog out must be done via discrete HW and mutliplexing (using some digital outputs).
…Depends on type of project
– Dealer located in Canada – no local store - so we have to wait for boards / components.

About you (from our current point of view):
Positives:
++available at our local dealer
++pricing (at least for the 8055 which is about half the price of the competitors board)
++analog output (althoug I’m not sure about PWM with 8055)
++with 8061 8 analog out (great for some project types)
Negatives:
–large formfactor (at least for 8061)
–for digital input (sensoring) we need to build discrete HW (multiplexing) or use 8061
–Possible problems with DX (some versions)
… most of the time our boards run on a server - not that problem.
–To integrate your boards smoothly in our environment an abstraction layer must be built
…not that problem if a documentation of the HID is available

Conclusion:
Some things are not clear at the moment (therefore I write here :slight_smile:)
Availability at the local dealer is a really great benefit!!!
Some pros / cons depend on the project type.
Especially at “larger projects” (more sensoring) we have not a big problem with the form factor / cost of the 8061 - instead it could avoid the need for discrete HW.

To build a reliable “driver” (.NET component) should not be a problem.
At least not if documentation about the HID Communication is available.

Regards

Manfred
PS: Please excuse my english - I’m from Austria :slight_smile:

[quote]In the DLL Manual of the 8061 I found a function “OutputPWM”.
BUT I could not find such a function for the 8055.
Is there something missing in the documentation???[/quote]
The PWM output’s duty cycle is proportional to the corresponding DAC output.

[quote]We found that some of the “old” DLLs are available as pascal source.
From that we learned that the handling is primarily done vie the HID interface.[/quote]
Yes, the card uses HID interface.
There are no interrupts - you have to poll the card. This may be no problem: New data is available every 10 ms.

Thanks for the fast response.

Open questions:
My assumption:
I have two cards. App1 opens card 1. App2 opens card 2.
If App1 one calls CloseDevice - only the communication to card 1 is stopped.
App2 can still interact with card 2.
Am I right?

And much more important:
Is there a documentation about the HID Data available / used?
Is there a list about the VIDs / PIDs used?

It is OK if you send me an email (I guess you can access my profile data).

Regards

Manfred

I have to do some testing before answering your question concerning the CloseDevice function.

Do you mean the data transferred to/from the K8055. - I think the only documentation is the source of the DLL.

VID 10cf Velleman Components
PID 5500 K8055 (address=0)
PID 5501 K8055 (address=1)
PID 5502 K8055 (address=2)
PID 5503 K8055 (address=3)

OK,

I’ll give the 8055 a try today.

And I asked you the question about the HID Data (Format of the Data-Blocks) because I thought you are “at the source”.

Anyhow – I guess it is not that much work to find out how the things are coded.
I’ll let one of my employees soldier the thing this afternoon - so (I guess) in the next two day we will see what’s going on.

If you are interested I’ll keep you informed here about the status of this evaluation.

A last few words about our “feelings”.
Your Support is fast and your try to provide as much info as possible.
There is a little “lack in information flow”.
–You can’t provide us with HID data
–You had to browse the internet to find VID / PID :slight_smile: (Great that you did this).

Thanks again

Manfred

Indeed - had to use internet to find the VID/PID - fast and easy :slight_smile:

Yes, it would be interesting to read how your evaluation project proceeds…

[quote]My assumption:
I have two cards. App1 opens card 1. App2 opens card 2.
If App1 one calls CloseDevice - only the communication to card 1 is stopped.
App2 can still interact with card 2.
Am I right?[/quote]
You are right:
If App1 one calls CloseDevice - only the communication to card 1 is stopped.

And thank you again :slight_smile:

So,

now the things are a lot clearer. :smiley:
We bought 2 boards gave them a test - and learned a lot.

Anyhow - we have a very basic implementation of a .NET component for the K8055 device.
This thing has notifications about board removement (or plug on), works mutlithreaded, allows you to access the elements by properties
if(myBoard.Digital2)…
works with an intelligent queue, has selective events.
For an example you can say:
Please react if Analog1 changes for more than 3 (because of flickering) and such things.

At the moment some “numberd accessors” and a view events are missing.
Last not least we want the class to be observable so that we can use the board in WPF with almost no code at all 8) – simply use native binding.
Something like
<button Enabled=“{Binding Path=Board1.IsPresent}”…
or
<gauge Value=“{Binding Path=Board1.Analog1}”…

You can take a look at the current (rough and dirty) helpfile:
ttncf.pp-p.net/K8055Hlp.zip

I’ll keep you up to date about the further progess.

Regards

Manfred

And WPF is done.
We’ll have to run the things in some stress test (currently it blinks next to me :slight_smile:).

But (except two or three Events) we are done.
The helpfile (link in prev. post) has been updated.

It works in WPF as expected.
Here is a very simple “application”.
It does:
Set Digitalt Out 1 - with a checkbox.
Set Analog (PWM) 1 and 2 with sliders.
Shows Counter 1 as number and Analog1 Input as progress bar.

The design code (and the result) looks like this:

Of course there is “code behind” - exactly 2 Lines I had to write :slight_smile:

By the way - we set AutoreadDelay (Refresh Frequenzy) to 100ms.
This seem to be high – but how fast are your eyes :slight_smile:

Of course it looks “nasty” - but this is just a proof of concept.
Design is an easy thing with WPF.

So we are happy with these (2 at the moment) boards.
The “large version” was not on stock at our dealer - but they will get it in the next weeks.

Regards

Manfred

Looks great! - Is the DLL available?

It will be finished in about 2 days (it will get 2 Methods and 1 Event added).
I’m not sure how we will proceed with this DLL - primarily it was made for “internal use” and took us about (based on information of the project management system) 80 man-hours developement time.

I guess you know the problems of “spread software”.
While we use it internal the 4 days stress testing and the relative low number (<100) of unit testing are enough.
If we have overseen an error, it will occure “at home” and we will simply fix it.

As soon as you spread such a thing (in which way ever) the level of needed quality insurance raises.

Anyhow - I’m sure we can find a way to give you a “velleman internal use only version” or such a thing :slight_smile:

Regards

Manfred

Yes, it may be interesting to get it for internal use.
Waiting for your tests to complete.

Hi

I would be absolutely static if the WPF implementation sample could be made available to me. I am absolutely desperate for it. Any chance it could be emailed to me???

Thanks

Sashah

Hi Vel255,

sorry for the delay - we are ready now.
I would need any way of “direct communication” so that we can send you the DLL + Dokus.
I did not find a “private message system” here in the forums, but I guess you can see my profile and grab my email address from there.

Regards

Manfred

Looks interesting…
You may contact me via e-mail address: vel255(at)diino.com

Hi

This looks great. Any chance of sending it to me to try out. I have purchaced a k8055 to send ttl signals to operate a maglock and card reader via a WPF interface.

Thanks

sashah

[quote=“sashah”]Hi

I would be absolutely static if the WPF implementation sample could be made available to me. I am absolutely desperate for it. Any chance it could be emailed to me???

Thanks

Sashah[/quote]

Hi Sashah,

what you see in the above post is the whole sample (code).
All assignments are made via bindings (which is common to WPF).

About the component itself - we are not sure what we will do with it.
There is a chance that we
a.) never give it away
b.) sell it on some kind of “per developer” basis
c.) share it some way

At the moment VEL255 has got it to see how it works.
We will keep you in mind - maybe we find a way to support you - regardless of the above possibilities.

Manfred

Hi

Ok well that’s something I can work on then. Can u give me an example of the bindings, do you mean referencing the COM component then building a wrapper?

Alternatively are there any .NET (c#) sample implementations I can use??

Hi Sashah,

with binding I mean native WPF Binding.
WPF binding uses “standard” technologies.

Normaly you have:
a.) a datasource or a dataobject
b.) you bind this source to some UI element
–this can be the window, or any other control in the app
c.) you bind a property of a control to an element (member) of the datasource or dataobject

In our case we use a dataobject (the K8055Board).
WPF will only refesh the data if the object notifies it about changes.
For this normaly the INotifyPropertyChanged interface is used (we do this too).

IMPORTANT!!
There is no COM object at all - our component is a native .NET component which use the HID interface to communicate with the board(s).
What does this mean?
You simply add a reference to the component (DLL) as with other .NET components.
From that moment on you cann access the component in your code.

From this point lets examine the above noted steps:
a.) a datasource or dataobject
–we have one since we have a reference to the K8055 component
b.) bind the source to some UI element
–we do this in code (Window_Loaded)
private void Window_Loaded(object sender, RoutedEventArgs e) {
DataContext = K8055XBoardHolder.Board0;
//the next is needed to have the component automaticly check for changed values
K8055XBoardHolder.Board0.AutoreadDelay = 100;
}

THIS is all the code you have to write – (in our simple case)
There is no more “hidden code” or something!!!
c.) you bind a property of a control to an element (member) of the datasource or dataobject
We do this in various ways.
Here are some examples:
Digital 1 Out
What we do here is - we create a Checkbox.
The “IsChecked” property is bound to the first DigitalBit of the datasource in the datacontext.

Lets explains this:
Our Datasource is K8055XBoardHolder.Board0.
This is an object of the type K8055Board (see documentation).
This object has an indexer for “DigitalOut”.
So the binding results in K8055XBoardHolder.Board0.DigitalOut[0].
In simple words - if you change the checkbox.IsChecked (by clicking or via code), WPF “sends” the data to the bound element.

Next we do it in the reverse way (a digital input):
Digital 1 IN
The difference - we set the binding mode to “OneWay” - since we can only read a digital input.
Since our component implements INotifyPropertyChanged WPF gets informed when something changes - and than it “rebinds” the data.
So this checkbox will be checked it the digital in on the board is set.

Another control:

This is a slider bound to the first Analog Output of the board - since Analog output values are given in a range form 0 to 255 we give this as min / max values of the slider.
When you change the slider value (via keyboard, mouse or code) - the Anlaog output on to board changes.

Last not least we display Anlaog1 input with a progress bar:

Again - mode=OneWay since we can’t set the analog input on the board.

A last few words:
The velleman DLL is NOT a COM component (AFAIK)!!
It is a native DLL.
We decided NOT to wrap the DLL - instead we built our own implementation.
There is a several reason for this.
a.) Multiboard handling is a bit complicated with the DLL
b.) Write / Read calls are synchronous
c.) To encapsulate those things (aspecially multiboard handling) would mean a lot of work
d.) We wanted full mutlithreaded access to multiple boards simultaniously
e.) We wanted controlled concurrent access to the boards.
–so several apps can read the board while another app writes to it
f.) we wanted a component wich runs partial trusted (of course IO and OS interop is needed)
g.) we wanted a compnent which can be used in services (IIS for an example) without limitations

The result are a bit more than 3.000 Lines of code - building a 39k component doing all the things described above.

I’ll again point to the image in this post: Multiple card programming and other Information required
What you see (the little window) is an app which does:
a.) Set / clear the first digital output bit when you check / uncheck the checkbox
b.) Set Analog1 / Analog2 when you move the sliders
c.) Display the value of counter one as number (45 in the example)
d.) Display the analog input 1 as progress bar (the green thing)

Behind the window you see the designer (XAML) and below the C# code of this application.

I hope my english was good enough to explain the things so that you can understand them.

Regards

Manfred