Thread: New Debugging Skin, and Logging Example!

very nice, im sure this will help alot... i know it woulda me two weeks ago :-)!

have you tried the outputs with this greenman?
when I tried them I thought they weren't working, but then I kept clicking 1 and finally I saw an output light up. so then I tried to hold the button to make sure it came on before I released, doing this helped me see why it wasn't looking like it worked, there is a near 1 sec. pause before it turns on, then again when you release the button there's the same pause before it shuts off. it seems like this should be closer to instantaneous, especially for momentary buttons. At first I thought it might be my computer so I tried it on my laptop and got the same pause.

Originally Posted by jimp

have you tried the outputs with this greenman?
when I tried them I thought they weren't working, but then I kept clicking 1 and finally I saw an output light up. so then I tried to hold the button to make sure it came on before I released, doing this helped me see why it wasn't looking like it worked, there is a near 1 sec. pause before it turns on, then again when you release the button there's the same pause before it shuts off. it seems like this should be closer to instantaneous, especially for momentary buttons. At first I thought it might be my computer so I tried it on my laptop and got the same pause.

Yup, it's all in the timers. Right now, they're set for 1 second. Adjust as you see fit.

I don't quite understand the timer stuff, is it just the output timer I adjust for this, and what effect on everything do the timers have?

ok i adjusted the output timer to "100" and that makes it pretty much instantaneous. one other thing I noticed with your skin is that the output buttons have the vote set to absolute, with it like this there is no "state" change of the buttons and therefore no sense in having both images. If I change this to "vote = attached" then I get a state change when I click. any particular reason why you had it set like this?

the timers are parts of the FCC software that actually execute the statements in logic, update graphics, and gather data from inputs, or send to outputs. the number you choose determines how frequently that part of the code executes. there's a counter in each timer section of the source that increments each time it cycles through. the value you put in the skin is when the counter says ok, I've incremented enough, time to actually do something now, and then it runs the code related to that section, comprised of both the hard code, and the code that has been read in from the skin. So if you pick a low number, you will get more samples of data, put data out more frequently, update graphics, or run logic faster, but your CPU usage will rise as well. Bigger number = slower.
outputs may be all you need, but the actual buttons are worked with in the graphic section, so you may need to adjust that too. Normally, in my experience if the timers aren't multiples of eachother or out of phase, data (button clicking) can get lost. But I'm not yet an expert on how that applies in this software yet (and there's nothing for phase adjustment).

cool, that explains why my attached image wasn't keeping up with my output, I adjusted the gui to 100 and now the button changes state as quickly as the output changes.

Originally Posted by h3rk

the timers are parts of the FCC software that actually execute the statements in logic, update graphics, and gather data from inputs, or send to outputs. the number you choose determines how frequently that part of the code executes. there's a counter in each timer section of the source that increments each time it cycles through. the value you put in the skin is when the counter says ok, I've incremented enough, time to actually do something now, and then it runs the code related to that section, comprised of both the hard code, and the code that has been read in from the skin. So if you pick a low number, you will get more samples of data, put data out more frequently, update graphics, or run logic faster, but your CPU usage will rise as well. Bigger number = slower.
outputs may be all you need, but the actual buttons are worked with in the graphic section, so you may need to adjust that too. Normally, in my experience if the timers aren't multiples of eachother or out of phase, data (button clicking) can get lost. But I'm not yet an expert on how that applies in this software yet (and there's nothing for phase adjustment).

Exactly!

As to the phase, the history on the analogue inputs could be used so if you only check logic 1 time out of 10 it firesm then in the logic you can do calculations based on any previous value as well to make up for the delay in processing. I would have to think about doing this automatically if the difference got too large I suppose. But that is something for a feature to come later!

Originally Posted by jimp

any particular reason why you had it set like this?

nope, just ended up that way