Page 6 of 6

Re: 2.x JimStim Support Request

Posted: Tue Nov 23, 2010 11:47 pm
by dandruczyk
Jimstim issues have been fixed. The tabs have been enhanced, and network mode for jimstim sweeping is disabled due to architectural limitations within MTX. Merged modular_0.1 branch to head and pushed.

Starting work on modular_0.2 for other modularization work.

Re: 2.x JimStim Support Request

Posted: Wed Nov 24, 2010 1:07 am
by Fred
Yay, jimstim on modular 0.1 works great, just a few minor complaints and a request :-)

input validation on the manual rpm input is absent or incomplete. you should be able to enter 0 and 60 - 65535, and not 1 - 59.

In the sweeper, when you enter both rpms wrongly, and then fix one, both go un red. this made it possible to enter 160000 rpm as the upper limit, and 0 as the lower, and generally break it. with the upper too high it overflowed and ended up maxing at 28000 and still displaying 160000. with min a 0 it just failed to work but didn't go red.

Also, when something goes red, how can I know what to enter to make it better? I happen to know but the next guy will be going "ok, its red, somethings wrong, but what do i put in next" tool tips (trying out your new fix tool tip fix) could be a fix, or just some text describing the operation of it in a box above or below would work too

Feature request: a check box for "as fast as possible" so i dont have to repeatedly enter 0.0001 and hit start, or accidentally end up going way slower. it could set the input as 0.00001 and do the calc and update the field just as before? or any other way you wanna do it :-)

Otherwise it works mint :-)

When you say "merged to head" you mean "merged to master" I guess. Does that mean that you took the functionality for jimstim and stuffed it back into master? or that master is now devoid of support for anything except jimstim and is modular? or what exactly? why not rename the branch just plane modular and work forward from it? rather than creating a new 0.x each time?

Just curious about what you're actually doing. Maybe there is a better way? Or maybe there is something I can learn? Fill us, or just me, in, please :-)

Fred.

Re: 2.x JimStim Support Request

Posted: Sat Nov 27, 2010 2:01 am
by dandruczyk
Fred wrote:Yay, jimstim on modular 0.1 works great, just a few minor complaints and a request :-)

input validation on the manual rpm input is absent or incomplete. you should be able to enter 0 and 60 - 65535, and not 1 - 59.

In the sweeper, when you enter both rpms wrongly, and then fix one, both go un red. this made it possible to enter 160000 rpm as the upper limit, and 0 as the lower, and generally break it. with the upper too high it overflowed and ended up maxing at 28000 and still displaying 160000. with min a 0 it just failed to work but didn't go red.
Fixed, wrong var sized resulted in overflow BEFORE the limit checker which caught me by surprise.
Fred wrote: Also, when something goes red, how can I know what to enter to make it better? I happen to know but the next guy will be going "ok, its red, somethings wrong, but what do i put in next" tool tips (trying out your new fix tool tip fix) could be a fix, or just some text describing the operation of it in a box above or below would work too
Both done, notification window that shows error messages as well as updated tooltips (only works if the user hasn't turned them off on the general tab however)
Fred wrote: Feature request: a check box for "as fast as possible" so i dont have to repeatedly enter 0.0001 and hit start, or accidentally end up going way slower. it could set the input as 0.00001 and do the calc and update the field just as before? or any other way you wanna do it :-)
You can't have your cake, and eat it too. If you select params that are technically unfeasable, then something needs to change, I can either red-error it, or make a best guess. You can keep the time if you change the RPM step, but donno what people wanted more, resolution or specific/exact intervals for the sweep to take. I supposed I could remove the "step" entry, and just let users enter in all three and it'll just go as fast as possible at all times, making up a step entry to suit, but it won't be perfect.
Fred wrote: Otherwise it works mint :-)

When you say "merged to head" you mean "merged to master" I guess. Does that mean that you took the functionality for jimstim and stuffed it back into master? or that master is now devoid of support for anything except jimstim and is modular? or what exactly? why not rename the branch just plane modular and work forward from it? rather than creating a new 0.x each time?

Just curious about what you're actually doing. Maybe there is a better way? Or maybe there is something I can learn? Fill us, or just me, in, please :-)

Fred.
CVS terminology dies hard. I don't necessarily like to have to keep telling users which branch/tag to pull/checkout, so I merged the work I had done to master (head in CVS terms), so noobs can easily pull and get those fixes and rebranched. I chose a NEW branch name vs renaming because I don't like to have too much stuff changed in a branch in case i introduce something bad and have to dig back to figure out what i messed up, so I take an iterative approach, i.e. modular_0.x as I move along, which lets me look back in time a LOT EASIER instead of having to remember dates, or commit hashes.

Re: 2.x JimStim Support Request

Posted: Sat Nov 27, 2010 2:13 am
by Fred
Everything sounds great (I will test shortly), except that I think you misunderstood this:
mtx_man wrote:
Fred wrote: Feature request: a check box for "as fast as possible" so i dont have to repeatedly enter 0.0001 and hit start, or accidentally end up going way slower. it could set the input as 0.00001 and do the calc and update the field just as before? or any other way you wanna do it :-)
You can't have your cake, and eat it too. If you select params that are technically unfeasable, then something needs to change, I can either red-error it, or make a best guess. You can keep the time if you change the RPM step, but donno what people wanted more, resolution or specific/exact intervals for the sweep to take. I supposed I could remove the "step" entry, and just let users enter in all three and it'll just go as fast as possible at all times, making up a step entry to suit, but it won't be perfect.
What I am talking about is setting parameters that cause it to be adjusted to say 159 seconds automatically, that is great, I like that autoness. But, then I adjust it to something else which should have a calculoated fastest sweep time of 3seconds and to get that, I ahvce to reupdate the time feild with 0.00001 and let it calc it again. It's easy to forget to do that. What I was asking for was a check box that always recalculates to the lowest possible number when the other three parameters are adusted. Does that make more sense? I hope so. If not, let me know. It's a faily minor gripe, anyway, though.

Fred.

Re: 2.x JimStim Support Request

Posted: Sat Nov 27, 2010 4:05 am
by dandruczyk
pushed up more tweaks, modular_0.2 branch

Re: 2.x JimStim Support Request

Posted: Sat Nov 27, 2010 2:20 pm
by Fred
Works great, Dave, no complaints at all :-) Famous last words... ;-)