Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

swisslizard

Content Provider
  • Content Count

    290
  • Joined

  • Last visited

  • Days Won

    22

swisslizard last won the day on August 11 2016

swisslizard had the most liked content!

Community Reputation

87 Excellent

2 Followers

About swisslizard

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1,859 profile views
  1. This is surprising. Driver issue? It seems to be some issue wich is influenced by more than one of several factors.: DOF and its timing of sending updates, USB driver, USB hardware, output controller hardware and firmware. The only thing I can influence is DOF. I'll add some extra config option the the for the PacLed64 output controller class, which allows to specify a minimum intervall between updates. If the timing is influencing the issue that could probably help. In most cases that extra delay will not have a effect, since the time between the updates is long enough anyway. Only if there are a lot of updates in a short time the extra delay would have a effect, but if that delay is small enough it will be hardly noticeable.
  2. There are really no changes apart from the logging. I did not even fix a small bug in the code that I found by mistake (nothing grave and very easy to fix). The logging code is not running in the same thread. There is a thread which only does the Pacled updates. When a update is sent to the pacled, the same data is also put in a queue for logging. In addition there is a timer firing every 5 seconds which empties the queue and writes the data to the file. The timer is a normal System.Timer object which means (if I'm not mistaken) that the elapsed event will run in a separate thread. Like that the impact on the thread sending the data to the pacled should be minimal and even if it has a impact that would only happen every 5 seconds or so. If you want to check the logging code, I'll be happy to post it. It seems that the problem we're trying to find is something which is influenced by the timing or frequency of updates and maybe also by the involved hardware (e.g. USB controller of your main board). This is probably also the reason why I never have these issues and other users experience them all the time. @xantari Just for curiosity, did you ever try to connect your pacled64 to another usb port or to put a usb hub between the pacled64 and the mainboard. I wonder if this has a effect.
  3. Very strange. Didnt change anything apart from the recording code. Will look at your data when I back home.
  4. I dont think that this is very likely. It is probably not even possible. IMHO development of the B2S Server should go towards a general Pinmame proxy which can handle various plugins. One plugin would be the backglass functionality, another would obviously be DOF. However before this can be done some cleanup of the code will be necessary.
  5. AFAIK they are still looking for someone who is willing to take over the maintenance and dev of the B2S.Server. The code is all vb.net.
  6. As promised I made a DOF version which records all commands which are sent to the pacled64 in a file. All Pacledled 64 commands and their parameters are written to the file PacLed64Data.txt in the table folder. Download is here: http://pinball.weilenmann.net/DirectOutput_Pacled64test_experimental_Build_6166_18436.zip Dont use the build for anythiung else than checking for problems with the pacled64 and remember to reinstall a normal DOF version after your tests, since the test version will generate a log file which grows bigger and bigger over time. File content The file is tab delimited which maikes it easy to open it in excel or some other program which can use delimited data. Column 0: Timestamp Column 1: Command Column 2: Index of the Pacled64 device Column 3-n: Remaining paras for Command as follows: SetLEDIntensities -> Intensity values for all outputs SetLEDFadeTime -> Fadetime SetLEDIntensity -> Outputnumber, Intensity SetLEDStates -> Group of Outputs (8 outputs are a group), State as Byte with Bitpattern for all outputs in the group The intensity command allow to set opacled64 outputs to the specified intensity. The state commands all9ow to turn a output off or to revert it to its last intensity value. Generally DOF tries to use the state commands to turn off outputs and to use the intensity commands to set output to a on state. If a lot of outputs (>30) have to be updated at the same time, DOF uses the SetLEDIntensities command, for small number of changes DOF uses the SetLEDIntensity repeatedly since this is faster. @xantari Please repeat the test you did with STNG and the clock on the BG screen with this DOF version, so we can check what is sent to the Pacled when the flickering occurs. To properly parse the data I'll also need a list of your output assignments. I screenshot of you pacled config page in the config tool will serve that purpose well.
  7. Yes the overall brightness can be reduced using fade curves. However, you shouldnt use a smaller psu anyway. The strips are dimmed using PWM, which means they are either fully on or fully off and therefore have the full power requirement. In addition there can alway somethings fo weong with thee config.
  8. Xantari has provided me with some more data to analyze. At first sight it looked like the problem is caused by incorrect data which is supplied to DOF, but that assumption turned out to be wrong. I think that the data which is sent to DOF is correct. Since this pretty much rules out the input side of DOF as a cause for these problem, we'll have to start checking some other things: The experiment with the reduced configs, as proposed in a previous post would still be a good idea. Unfortunately I cant do that myself, since I havent got any problems here. Here is the proposal again: Another thing which would be good to know, is which effect setting is causing the unexpected flickering and knocks. Typically tapping the flipper button will only triger the solenoid for that flipper and nothing else. In least in theory a config which links a solenoid event (for the flipper fingers often S47, S48 or S49) whith a contactor toy, cant trigger another toy by mistake. Testing this would require to modify the config (dropping everything appart from the configs for the flipper finger to contactor connection) for a table and then trying again if the problems still exist. If they dont, more effecst could be added for further checks until the problem is back again. If you can find out what combinations of effects are causing the problems, we might get a good step ahead. I'll try to make a experimental DOF version which logs all data which is sent to the Pacled64 device. This would allow to check for unexcpected data. If there is unexpected data, the cause for the problems must be in the toys or effects implementation. If there is no unexpected data, the cause for the problems is most likely in pacleds org driver dll.
  9. Hi guys Made a small plugin to record all data which is sent by the B2S.Server. Install that plugin like you install DOF (plugin folder of B2S.Server). The plugin runs in paralell with DOF and write all data it receives from B2S.Server to the file B2SEventData.txt in the table folder. Important: Dont forget to remove the plugin later on. Otherwise it will generate a HUGE file of table data over time. You can download this small hack here: http://pinball.weilenmann.net/B2SServerDataRecorder_not_even_alpha.zip The file with the event data contains 4 columns: Timestamp of the event Table Element Type (as defined here: http://pinball.weilenmann.net/docu/DirectOutputWIP/namespace_direct_output.html#a175aa273230ef2862f0ed4e5551ceb38) Table Element Number Table Element Value If you want to translate the table emement type and table element number to the actual table element, you'll need to download the tables manual from IPDB. The manual have pages on solenoids/flashers, switch matrix and lamp matrix where you can lookup the table elements. Xantari has already done a small first test with that plugin and provided me with the file of B2SEventData. Already found something slightly strange, but I'll need to check this with xantari first. Hope to have some more info soon!
  10. Will have to look into serilog. Sounds pretty good. Will send you a PM shortly.
  11. I have starteed to work on the recorder plugin. Should be ready soon. Replacing the logging in DOF with some better mechanism would be a good idea. However, please consider log4net if you try to change the logging. Be aware that adding logging statements to the threads doing the actual work in DOF might slow down the framework. It is not that hard. The columns in the ini file lines are delimited by comma. The configured effects per column (which relates to a toy) are separated by /. You can remove any number of effect configs from a column if you just remove the stuff between two /. If you have no more effects in a column, just enter a single 0 into that column. There is a bit more on the ini configs in the dof docu: http://pinball.weilenmann.net/docu/DirectOutputWIP/inifiles.html If you want to get rid of knocker configs check for effects which start with S7 (Solenoid 7). This is for many table the knocker. You can lookup the numbers of the toys for the configs in the manuals of the org pinball machines (can be found on IPDB).
  12. Yes, every event resp. command which is passed between Pinmame and the table script is passed to DOF. DOF put every input into a queue for further processing. The design ensures (I hope) that it is not possible to miss any data which is passed to DOF. I just made the diagram below to illustrate what is happening between table script, B2S.Server, Pinmame and DOF. DOF does only receive data which the B2S.Server intercepts from the Pinmame vs table script "communication". At least not be intention. A few additions have been made to allow for named table elements (used for PBX support), but apart from that everything should work the same it always did. There is no reason why R3 would be faster than R2. DOF wise there is also no timing thing involved when receiving data. All data is put in a buffer and reading the buffer is also not timing relevant. The reading thread is signaled when data is written to ensure that data is read as fast as possible. The only timing thing is kind of a alarm clock for the main thread of DOF which is required for updating effects which have a result which changes over time (e.g. fading). That part of the code has not changed recently. No, the dll is still the same, but there is a small change to reset Pacled64s built in fading to 0 in the output controller class for the pacled64. Way forward I still havent got a clue what causes these problems. Will try the following (but dont know how long it will take me to do this since I have just limited time): Comparison of the R2 code to the latest R3 code. That will be quite a bit of work since many new things (mainly for addressabled ledstrips) have been added. Will try to make a small B2S.Server plugin which will record all data which also received by DOF. I'm pretty curios to find out if there are any unexpected events recorded. If you have other ideas what could be checked to nail down that problem, please let me know. Another thing which would be good to know, is which effect setting is causing the unexpected flickering and knocks. Typically tapping the flipper button will only triger the solenoid for that flipper and nothing else. In least in theory a config which links a solenoid event (for the flipper fingers often S47, S48 or S49) whith a contactor toy, cant trigger another toy by mistake. Testing this would require to modify the config (dropping everything appart from the configs for the flipper finger to contactor connection) for a table and then trying again if the problems still exist. If they dont, more effecst could be added for further checks until the problem is back again. If you can find out what combinations of effects are causing the problems, we might get a good step ahead.
  13. @xantari Your DOF frontend screenshots look normal.
  14. @xantari & @arngrim Please try zebulons suggestion with the different backglass. This is a good idea to rule out problems coming from the backglass (I think it is a unlikely cause, but you never know). Just copy the backglass of a table which doesnt have those issues and rename it the name of the org backglass file for that table. If you do this the backglass will most likely show no or wrong effects, but for the test to check whether the backglass is involved into the problem that is not relevant. Another similar test scenario would be to remove the backglass of the critical tables. The B2S.Server does also work without a backglass and it does still forward the event data to DOF. If the problem we're trying to track down is caused by the backglass, everything should work fine withouth the backglass.
×
×
  • Create New...