Worked a Bunch This Weekend

[kendall...@gmail.com]

Well it has been a while, but I thought I'd note that I worked a bunch
this weekend and have been doing a lot of coding to get the pin
going. With this I thought I'd post a question to people here that
may be able to help. Some of this is abbriviated and I can fill in as
people respond. Here is the basic issue I'm trying to rectify:

The machine is all being programmed in VB.net (yes I'm doing VB
because it is an environement that is free and somewhat easy to
program in) and basically I’m using this board to push a mosfet to
control the solenoids:

http://www.u-hid.com/home/index.php

I basically use their LED function to run the fet. What I have going
that is boggling me is that using their test function (code is
included in the download page below) with just a start and stop button
to push the fet the solenoid fires strong and then pushing the turn
off button it kills is nice and strong.

So that is no problem. When I try to set up switch hit control via a
keystroke it will fire fine also. Problem with this situation is that
I need it to turn off the solenoid/fet pretty quickly as to not blow
the fet or overheat the solenoid. My programming solution was to run
a timer tick function that would initially fire the solenoid and then
on the second tick turn it off. This solution kindof works but I get
a really weak fire (for upkickers it is way too weak). I’ve tried to
mess with the tick length, but there really is not sweet spot for
this. I’m wondering if there is another way of fixing this.
Thoughts?

I can send through the code later if you think you might have ideas.
Here is their initial code for working with it.

An SDK produced by Ben Baker is available http://www.ultimarc.com/PacDriveSDK.zip

This is a universal SDK for the PacDrive and the U-HID boards. It can
be used with combinations of these two board types. PacDrive boards
will be enumerated first, starting with ID #1 upwards, followed by U-
HID boards starting with ID #1.
This contains a universal DLL which is very simple to use as it only
has 3 calls. There are also source code examples for VB6, VB.NET,
Delphi and C#
The DLL calls are described in the "readme" file.
The C# and .NET examples flash the LEDs randomly, VB6 and Delphi turn
the LEDs on using a fixed pattern.

[Adam Preble]

Ken,

From your description it sounds like your timer tick method is not accurate enough to consistently and precisely control the output.  This is a very common issue with modern operating systems.  Even if it doesn't look like it the OS is busy with a lot of stuff other than your application, so timer events tend to come "when it gets around to it."  You can do things to try to improve upon this (such as running a very tight loop that continuously checks the time), but it's always going to be an issue -- there's always the possibility that the OS will decide to swap out some memory for a second or two while you have that coil on.

There's also a strong possibility that the latency between your code and the board (over USB) is high and inconsistent enough to making it even harder to get precise control.  This latency largely depends on what kind of drivers they are using and so forth.

As I see it there are two/three possible solutions:

1) Write a Windows kernel driver to control the USB board and do all of your timing-sensitive operations there.  (I would not recommend pursuing this; kernel drivers are horrible, horrible things, unless you are a very special kind of person.)

2) Use a hardware control system:

a) Use something like P-ROC, or some other embedded control system.  Personally I would recommend looking at P-ROC; you can probably set it up to drive your mosfets (I'd post on the forums and ask).  It's built exactly for this sort of thing -- pulsing a driver for X milliseconds, or even pulsing a driver in response to a switch event -- all in hardware.  Now there is even the beginnings of a .Net interface to the control library, which would be perfect for your interest in using VB.net.

b) Alternatively you might be able to use something like an Arduino to drive the mosfets.  You'd need to write a program in C on the Arduino to listen for serial commands over USB and then it would handle driving the mosfet for a more precise amount of time.

Adam

--
You received this message because you are subscribed to the Google Groups "Homebrew Pinball" group.
To post to this group, send email to homebrew...@googlegroups.com.
To unsubscribe from this group, send email to homebrew-pinba...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/homebrew-pinball?hl=en.

[kendall...@gmail.com]

Well that is disappointing to hear that I'm getting screwed by the
operating system. That kinda makes sense though. I was really hoping
to make this method work. I have looked at the P-ROC and the going
the Arduino route too. On the P-ROC it was simply a money issue. I'm
not questioning their pricing, I know that those things are not cheap
to make, but they are somewhat out of my price range. Spending $70 -
100 multiple times is a lot easier. I'm also just not much of a c
programmer, maybe I should bite the bullet and figure that out.
Regardless here is my vb code if someone has ideas:


Public Class Form1
Dim pacDrive As PacDrive = New PacDrive()
Dim solenoidtimer As Timer = New Timer()
Dim numDevices As Integer = pacDrive.Initialize()
Dim pitsolenoidon As Integer = 0

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click

' This is the Start Button

pacDrive.SetLEDStates(0, New Boolean() {False, False,
False, False, False, True, _
False, False, False, False, False, False, _
False, False, False, False})

End Sub

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button2.Click

' This is the Stop Button

pacDrive.SetLEDStates(0, New Boolean() {False, False,
False, False, False, False, _
False, False, False, False, False, False, _
False, False, False, False})

End Sub


Private Sub solenoidtimer_Tick(ByVal sender As Object, ByVal e As
EventArgs)
If pitsolenoidon = 0 Then
pacDrive.SetLEDStates(0, New Boolean() {False, False,
False, False, False, True, _
False, False, False, False, False, False, _
False, False, False, False})
pitsolenoidon = 1
End If

If pitsolenoidon = 1 Then
pacDrive.SetLEDStates(0, New Boolean() {False, False,
False, False, False, False, _
False, False, False, False, False, False, _
False, False, False, False})
pitsolenoidon = 0
solenoidtimer.Enabled = False
End If

End Sub


Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load

End Sub

Public Sub TextBox2_KeyDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles TextBox2.KeyDown

' Functions For Switch Hits

If e.KeyCode = Keys.C Then

'Sets Solenoid Function

solenoidtimer.Interval = 25
AddHandler solenoidtimer.Tick, AddressOf
solenoidtimer_Tick
solenoidtimer.Enabled = True

End If


End Sub

End Class

[Eli Curtz]

You can always use the U-HID for switch inputs or another project. I've collected quite a few little bits of hardware at this point.

There are some microcontrollers that you can program in languages other than C, you could check them out as possible Arduino alternatives. Parallax has Basic Stamps, and there are others that can use either "Spin" or C. I'm not guaranteeing these would work for your solenoids, but they'd be worth investigating.

Even though you don't have the control you need, turning that first coil on is pretty exciting!

Eli

Sent from my iPad

[kendall...@gmail.com]

Yes definitly. It worked pretty well for regular plungers. This
video here is it working with the outlane kickers and running pretty
well, I was this far 2 years ago and am now finally getting back to
where I was. I may go in and really try to strip down what is running
on the pc to see if it helps.

I'm very close on this.

http://www.youtube.com/watch?v=Sdvy2HAgUEI

My problem is I don't have the code I used for this video. It got
lost in work and sadly enough I can't find it. It seemed to work
better then my current situation.

On Nov 30, 9:39 am, Eli Curtz <e...@nuprometheus.com> wrote:
> You can always use the U-HID for switch inputs or another project. I've collected quite a few little bits of hardware at this point.
>
> There are some microcontrollers that you can program in languages other than C, you could check them out as possible Arduino alternatives. Parallax has Basic Stamps, and there are others that can use either "Spin" or C. I'm not guaranteeing these would work for your solenoids, but they'd be worth investigating.
>
> Even though you don't have the control you need, turning that first coil on is pretty exciting!
>
> Eli
>
> Sent from my iPad
>

> On Nov 30, 2010, at 6:11 AM, "kendallvanp...@gmail.com" <kendallvanp...@gmail.com> wrote:
>
>
>
> > Well that is disappointing to hear that I'm getting screwed by the
> > operating system.  That kinda makes sense though.  I was really hoping
> > to make this method work.  I have looked at the P-ROC and the going
> > the Arduino route too.  On the P-ROC it was simply a money issue.  I'm
> > not questioning their pricing, I know that those things are not cheap
> > to make, but they are somewhat out of my price range.  Spending $70 -
> > 100 multiple times is a lot easier.  I'm also just not much of a c
> > programmer, maybe I should bite the bullet and figure that out.

> > Regardless here is my vb code if someone has ideas:- Hide quoted text -
>
> - Show quoted text -

[Gerry Stellenberg]

I'd be surprised if you couldn't get the timing you needed out of your OS, assuming you were able to strip out everything you don't need.  After all, isn't that how systems like P2k/nucore and games like Coconut Island work?

The USB latency is a bit more worrisome to me.  We've noticed unpredictable USB timing during P-ROC dev, but that's one reason why we don't use USB bus for real-time control.

Do you have an oscilliscope you can use to measure the exact timing you're getting on your coil pulses?  I would think you could print some debug messages in your code to get the timing data from your OS (assuming the messages don't affect the timing) and compare that to your hardware timing measured with a scope.  Then you would know the source of your variable timing.

- Gerry

[William Brower]

Kendell,

I forwarded this to my nephew who is a computer programmer. I'll see if he can help in anyway.

We too are using the Arduino as our hardware of choice on the PC side of our build. 

Nothing against the P-Roc, but it just does not fit in our budget either. Remember we are building 3 machines.

We will not have any problems with solenoid's overheating because our machines are all electromechanical. These would play as a regular em style games. We will have relays with N/O and N/O contacts sending signals back to the PC Via the Arduino. So the solenoid's would fire and send the signal back to the pc. Plus these will be fused accordingly.

Don't give up at what you are doing. It sounds like your on your way.

Good Luck on Your Build.

Bill

On Mon, Nov 29, 2010 at 2:03 PM, kendall...@gmail.com <kendall...@gmail.com> wrote:

[William Brower]

correction: We will have relays with N/O and N/C contacts.....sorry

On Nov 30, 6:05 pm, William Brower <jerkymanbrow...@gmail.com> wrote:
> Kendell,
>
> I forwarded this to my nephew who is a computer programmer. I'll see if he
> can help in anyway.
> We too are using the Arduino as our hardware of choice on the PC side of our
> build.
> Nothing against the P-Roc, but it just does not fit in our budget either.
> Remember we are building 3 machines.
>
> We will not have any problems with solenoid's overheating because our
> machines are all electromechanical. These would play as a regular em style
> games. We will have relays with N/O and N/O contacts sending signals back to
> the PC Via the Arduino. So the solenoid's would fire and send the signal
> back to the pc. Plus these will be fused accordingly.
>
> Don't give up at what you are doing. It sounds like your on your way.
>
> Good Luck on Your Build.
>
> Bill
>

> On Mon, Nov 29, 2010 at 2:03 PM, kendallvanp...@gmail.com <

> > homebrew-pinba...@googlegroups.com<homebrew-pinball%2Bunsubscrib e...@googlegroups.com>
> > .

[Adam Preble]

On Tue, Nov 30, 2010 at 2:12 PM, Gerry Stellenberg <gstell...@gmail.com> wrote:

I'd be surprised if you couldn't get the timing you needed out of your OS, assuming you were able to strip out everything you don't need.  After all, isn't that how systems like P2k/nucore and games like Coconut Island work?

P2K's operating system is based on modifications to an operating system called PC-XINU[1].  These modifications turned it into a RTOS, which is getting into areas outside of my expertise but suffice to say that it's very much unlike a desktop operating system.  As I understand it it all boils down to how the task scheduling works.

I don't know enough about Nucore or Coconut Island to comment on their architecture or performance.

It's probably possible to strip down the OS so that 95+% of the time it runs great.  And by that I mean that *most* of the time it will respond snappily to switch state changes.  But if you need any sort of accuracy as far as how long to drive a solenoid for, such as for driving flippers in the modern style (where the EOS switch is not used and the main coil is driven for a programmed amount of time), or pop bumpers that are snappy but don't lock on if the switch gets stuck, I believe you need a hardware solution (or a RTOS, which is probably not practical for most of us) to get consistently good results.

I realize that my standards for responsiveness/etc. are pretty high.  However, if I'm going to be spending time on a pinball project like this, I want to be writing game software and rules, not fighting with latency/timing issues caused by my control system.  I also want the game to be just as rock solid as the originals.

Adam

[1] http://www.pinrepair.com/pin2000/xina.htm

[Gerry Stellenberg]

It's probably possible to strip down the OS so that 95+% of the time it runs great.  And by that I mean that *most* of the time it will respond snappily to switch state changes.  But if you need any sort of accuracy as far as how long to drive a solenoid for, such as for driving flippers in the modern style (where the EOS switch is not used and the main coil is driven for a programmed amount of time), or pop bumpers that are snappy but don't lock on if the switch gets stuck, I believe you need a hardware solution (or a RTOS, which is probably not practical for most of us) to get consistently good results.

Expanding on this point a bit, even if your OS runs perfectly 100% of the time, there's still an issue with USB latency that will affect flipper/bumper timing.  If you figure 20-30ms for a USB packet (this seems to jive with what I've seen), then it could take 30ms for software to receive a switch event (flipper button or pop bumper switch) and 30ms to send the coil activation command.  Ignoring any software processing time, you're at 60ms of latency.

The P2K/Nucore/CI guys didn't have to worry about this latency nearly as much because they're using parallel ports, which carry much less latency.  Of course, they present other issues.

In my experiments using software switch handlers for flippers and pop bumpers, the latency was definitely noticeable, but the game was still generally playable.  

You'll have to decide if the latency is acceptable to you.  If it is, then your current solution might be ok (if you can work out your OS timing).  Otherwise, you might want to look into an embedded controller of some sort to help out (arduino, propellor, P-ROC, etc).

- Gerry

[kendall...@gmail.com]

Thanks everyone for your input! I may try to go the Arduino route.
What would people suggest for this?

http://www.sparkfun.com/products/9949 Would this one work any other
suppliers that are good?

On an aside, right now I have my flippers, pop bumpers and slings hard
wired and not integrated into the CPU (like an EM). So that hasn't
been a problem with the latency, however how this goes may make me
considering integrating them.

Ok this said and pardon if I seem a little ignorant here, but I want
to make sure I have this solution correct (never used and Ardunio
before).

- Ardunio has code on it so it doesn't interface with cpu to fire the
solenoid via a fet.
- Switch would then need to be wired directly to the Ardunio board so
the input wouldn't go through the CPU either to fire the solenoid.
- You would program the Ardunio to send the switch hit to your
computer so it could integrate with the overall game program.

Or do you continue to have the switches read by the CPU and then send
code via usb to Ardunio? This seems to me to defeat the purpose of
doing this? Am I missing something?

[Gerry Stellenberg]

Without getting into specifics, anything that needs precise timing and/or immediate reaction times should be implemented in the embedded device.  Things that don't require precise timing and/or immediate reaction times can be implemented on your PC.

- Gerry

[Adam Preble]

On Wed, Dec 1, 2010 at 10:44 AM, kendall...@gmail.com <kendall...@gmail.com> wrote:

http://www.sparkfun.com/products/9949  Would this one work any other
suppliers that are good?

SparkFun is a great vendor, and that would probably be the board to use.  There are a lot of great examples available for the Arduino; you can see some of them here: http://arduino.cc/en/Tutorial/HomePage

You might look into the Netduino as well (http://netduino.com/) ... which appears to run .Net code on an Arduino-like platform.  I haven't used it but depending on your comfort level with C and pointers and so forth it might be a more comfortable environment.

Adam

[Chris Moates]

 - Ardunio has code on it so it doesn't interface with cpu to fire the
solenoid via a fet.
 - Switch would then need to be wired directly to the Ardunio board so
the input wouldn't go through the CPU either to fire the solenoid.
- You would program the Ardunio to send the switch hit to your
computer so it could integrate with the overall game program.

You have this basically correct. You'd write some Arduino code that watches for the switch hit and fires the solenoid. It would also, via some method (USB perhaps) communicate back to your computer that the switch had fired, so you can add score, change game modes, whatever. Essentially you'll have a control/signal channel between the CPU and the Arduino, and the Arduino will handle, as Gerry said, anything that requires precise timing.

The only place this might get hairy is if you need to have the CPU know something in real time with the Arduino. But I don't know that that will be much of a problem, a game mode started 30-100ms too late isn't going to be a big deal, I wouldn't think.

The Arduino programming language isn't bad at all, and the boards are cheap. The Mega that you have there is what I have. Arduino code however is portable, so if you wanted to start out lower budget, you could get a unit with less I/O and do your proof of concept there, then graduate up to a larger unit as you become comfortable that it's the right direction. Or use both at the same time for more inputs, if needed.

Cheers,

Chris

[Steve Shoyer]

On Wed, Dec 1, 2010 at 10:44 AM, kendallvanp...@gmail.com <

kendallvanp...@gmail.com> wrote:

> http://www.sparkfun.com/products/9949 Would this one work any other
> suppliers that are good?

I've bought items from Sparkfun, and they've got a good selection.
MakerShed (http://www.makershed.com) also has a lot of Arduino etc.
accessories. My latest Arduino component was a PWM driver kit from
MakerBot (http://store.makerbot.com/pwm-driver-v1-1-kit.html), which I
plan to use in my homebrew machine to control some magnets
(eventually).

--Steve

[kendall...@gmail.com]

I just thought I'd update the group that I haven't done any testing
just yet. I've had a couple busy nights and will be working on this
over the weekend. I'll update folks on monday. Thanks everyone for
your thoughts and help!

[kendall...@gmail.com]

Well I solved the problem with the UHID and it was a coding issue more
then a latency issue. The latency issue may still exist, but I have
my flippers, slings and pop bumpers all hard wired right now (not sure
if that is the right term but I'll use it for now).

The issue with my code was the timer tick function was either turning
off the solenoid too quickly or not at all, so my solution was to kick
the solenoid outside of the timer function and then turn it off with
in the timer function. I'm going to get all of the solenoids wired up
and I'll get off a video for you folks when I have that done

Here is the code that works:

solenoidtimer.Enabled = False

End Sub


Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load


End Sub


Public Sub TextBox2_KeyDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles TextBox2.KeyDown


' Functions For Switch Hits


If e.KeyCode = Keys.C Then

pacDrive.SetLEDStates(0, New Boolean() {False, False,
False, False, False, True, _
False, False, False, False, False, False, _
False, False, False, False})

solenoidtimer.Interval = 300

[kendall...@gmail.com]

If anyone is interested here is my quick video of the work. It isn't
that great because of the light and other such things, but hey you can
see it in action.

http://www.youtube.com/watch?v=6id42bIegl8


On Dec 12, 10:54 am, "kendallvanp...@gmail.com"

[White_Spot™]

Nice work kendallvanpool.

[kendall...@gmail.com]

Thank you. I'm planning on being much more active here so you all
have to put up with my ramblings ;-P

On Dec 13, 5:30 pm, White_Spot™ <White_S...@netcabo.pt> wrote:
> Nice work kendallvanpool.