29 replies to this topic

[Outhere]

When you installed the latest version did use the installer?

-

Did you install over the top of the old one or in a new folder?

[widget2k13]

I have done full clean reinstall of the complete system several times since I built tha cab with same results every time , the supplier of the pc2 boards has the same problem with delay and non firing of the contractors on all his pins so maybe that could rule out dof software ?
I am not that clued up on it tbh and other people have always done the software for me

[DDH69]

If you think about the layers involved in this you have;

For VPX -

Table file - VPX - B2SServer - DOF - Windows IP Stack - network - Pincontrol2 network Hardware - PinControl2 Firmware - Pincontrol2 outputs / booster - solenoids

 

For VP9

Table file - VP9 - B2SServer - DOF - Windows IP Stack - network - Pincontrol2 network Hardware - PinControl2 Firmware - Pincontrol2 outputs / booster - solenoids

 

For FX3

Table file - FX3 - DOFLinx - DOF - Windows IP Stack - network - Pincontrol2 network Hardware - PinControl2 Firmware - Pincontrol2 outputs / booster - solenoids

 

Each layer only knows about the one before and after it. The most similar scenarios are VP9 and VPX,  If VP9 works and VPX doesn't then it would be illogical for it to be the output controller (PinControl2).  Of course, this theory only holds true until disproved.

 

I would be looking first at the B2SServer layer and its installation as its the thing that both VPX and VP9 drive into.  Having said that, I'm not sure what I would look at !  That is made worse given that you say the reseller has the same issue, that implies commonality between your setup and theirs.  Have you by chance setup B2SServer using common instructions (that may be too good to be true, but thought I'd ask)

 

If you change to another controller you would change a lot of items in the layers, ie if you used a PinScape with VPX it would look like;

Table file - VPX - B2SServer - DOF - Device Driver - USB Layer - USB controller - USB Port - Pinscape USB Hardware - PinScape Firmware - Pinscape outputs - booster - solenoids

 

I know there is a lack of suggestions here, but given the number of times I've run through the layers, setup various controllers, etc, thought I'd write up my thoughts in the hope of shaking an idea loose in my, or someone else's head.

[widget2k13]

the trouble is most of it doesn't make sense to me i dont know how to change any settings in b2server ?

i have just uninstalled dof and reinstalled it fresh with the installer and its still the same 

[zebulon]

Not to take away from the PinControl system but I believe that it is using DMX for output control.  I'm fairly certain that DMX works great for lighting effects (you never really notice the delays) but has certain timing issues as it was never fully tested for full system control.  I looked at doing the same thing a few years back and quickly ditched it due to the timing issues.

 

One of the layers left out in the above post could be considered to be B2SServer -- DOF -- DMXController -- LedWiz Equivalent -- Windows IP Stack -- etc ....  ultimately everything comes back to translating to the ledwiz equivalent for final output control. 

 

I always felt the issue lay in the potential number of instances that DMX controller had ... (number of universes) x (number of outputs per universe) = (a larger data stream to parse for.)  It doesn't look at all of it of course, you do assign the parameters in the setup, but it has to be ready for it if it does show up.    

[DDH69]

Thanks for the correction to the layers, I clean forgot those as I don't get into the DOF code that often.

[DDH69]

Not to take away from the PinControl system but I believe that it is using DMX for output control.  I'm fairly certain that DMX works great for lighting effects (you never really notice the delays) but has certain timing issues as it was never fully tested for full system control.  I looked at doing the same thing a few years back and quickly ditched it due to the timing issues.

 

One of the layers left out in the above post could be considered to be B2SServer -- DOF -- DMXController -- LedWiz Equivalent -- Windows IP Stack -- etc ....  ultimately everything comes back to translating to the ledwiz equivalent for final output control. 

 

I always felt the issue lay in the potential number of instances that DMX controller had ... (number of universes) x (number of outputs per universe) = (a larger data stream to parse for.)  It doesn't look at all of it of course, you do assign the parameters in the setup, but it has to be ready for it if it does show up.    

 

A late thought on this.  The clarification on this is great, and clearly a point of view on DMX which I don't know enough about to comment on, but the issue remains this is reported as working with VP9 and then problems with VPX.  If DMX (or other) architecture was the problem, why isn't the symptom apparent on VP9?

[DDH69]

OK, I hate a mystery, but still haven't solved the actual issue in this post.  What I have done is setup to test the response speed of a few output boards.  Based on zebulon's post I was genuinely worried about the speed of the PinControl2 - but spoiler alert, nothing to worry about.

 

What I've done is setup to time from the point the controller board is told to turn on or off to the point it reacts.  I've done this by modifying a standard game controller (seen as a joystick with buttons by DOFLinx) to have an optocoupler across one button.  Then change the powering of that optocoupler to different board outputs.  So that means, turn on an output then time how long until the joystick button is pressed.  To remove odd timing variables I've allowed it to run up to 100 loops and then show the average.  The test results below from what  I've done have been over 100 loops.  I've written the code for this in DOFLinx, so anyone can now do this test.

 

 

One thing to remember of course is that the timing includes the time for the joystick button press to be detected.  So the actual time to the reaction of the board is a little lower than shown.  However, given that I used the same joystick controller (and same PC) for all tests, then the time added by the controller is constant, probably a few mS.

 

Anyway, onto the results ....

 

PinControl1 - average on time = 293.7mS, average off time = 112mS

PinControl2 - average on time = 38.7mS, average off time = 41mS

Pinscape - average on time = 34.7mS, average off time = 40.4mS

 

This shows that the PinControl2 using DMX is essentially the same as the USB based Pinscape, so no DMX overhaed.  Obviously the Pincontrol1 is comparatively slower with nearly 300mS to turn on - but I suppose that's why there is a PinControl2 !

 

I hope to be able to test a LEDWiz soon.  The real problem is that the only two of those I have are fully wired in my cabinet.

 

So the mystery of why VPX causes the original issue and not VP9 remains.

[Adeysan]

Im just having delay problems with bumpers slingshots flippers etc going off , and sometimes not going off at all , I know its not really a huge issue to some people but to me it makes vpx unplayable and not enjoyable when contractors are firing at the wrong time or not at all sometimes , was just looking for an easy cheaper alternative board to try in

 

 

Hey widget - did you ever find a solution for this?

 

I've been having exactly the same issues since 'finishing' my PinControl cab recently.  It seems to me the the bumpers lag if there is too much other DOF stuff going on - especially fading lights.  I've been able to pretty much 'solve' the issue by using the 'remove button fade' setting in DOF config, and also setting my Undercab lighting to Smart (not complex).

 

Some tables still lag a little for me at first (ACDC, Star Trek LE, MM), but can generally be fixed by removing/replacing any fancy Undercab/button fade settings in the relevant DOF *table* config.  Not ideal, but it doesn't really affect the lightshow too much, and you get your snappy contactors back.

 

I would for sure like a real solution to this though.

[zebulon]

I've separated my controller line into separate boards for this reason.  I use a dedicated lighting board and a separate board for everything else.

 

When you send a pwm signal for lighting colour it's a static setting (intensity and light colour assignment remain the same) so the variables per cycle remain the same.  Fading lights involve a loop decreasing the intensity with each cycle through the loop.  Since the average microcontroller isn't threading the process you have to wait for the designated number of cycles to pass before proceeding onto the next command, in this case you wait for the light to fade before triggering the solenoid.

 

Using two separate controllers moves away from this issue (or at least puts the timing issues onto the lighting which is harder to notice).