 | | Re: global output control
|
|
(...) It's a perfectly good word! (It's not in M-W, but OED has it. And M-W has "obverse"....) :) And, it describes exactly what you want. (24 years ago, 20-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: global output control
|
|
(...) I was thinking of RestoreOutput myself, but then I was wondering if it implied restoring the enable/disable state as well. I'd like to keep the calls 'paired' as much as possible... EnableOutput / DisableOutput InvertOutput / ???Output I know (...) (24 years ago, 20-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: global output control
|
|
Just had to add my two cents worth; NegateOutput RestoreOutput JB (24 years ago, 20-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: global output control
|
|
(...) What's wrong with Obvert? (24 years ago, 20-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: global output control
|
|
(...) How about DontInvertOutput? Not beautiful, but IMHO clearer. Jürgen (24 years ago, 20-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: global output control
|
|
"Matthew Miller" <mattdm@mattdm.org> wrote in message news:slrn8kshgc.sof.....bu.edu... (...) first, (...) It won't do any good to call Revert without Invert though... I guess one confusion with Revert is that it wouldn't switch the output back to (...) (24 years ago, 19-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: global output control
|
|
(...) The only problem is that "revert" implies that invert must be called first, and I don't think that is the case. (24 years ago, 19-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: global output control
|
|
"Matthew Miller" <mattdm@mattdm.org> wrote in message news:slrn8kpub3.v5a.....bu.edu... (...) "RevertOutput". (...) I think RevertOutput is fine. I actually wonder how often that call will end being used in user's programs? The InvertOutput command (...) (24 years ago, 19-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: global output control
|
|
(...) ObvertOutput? (24 years ago, 18-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | global output control
|
|
The Scout and RCX 2.0 both support what lego calls "global" control of the outputs. At first I thought the global calls somehow took precedence over normal calls, so I simply made global versions of all the output calls in NQC. However, after (...) (24 years ago, 18-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: NQC 2.x event processing
|
|
(...) <snip> Dave, Been out of town, and will look more at your messages this weekend. Thanks for the feedback. -- Gordon (24 years ago, 15-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: NQC 2.x event processing
|
|
(...) Getting things like Timer[0] = 100; to work while still allowing if (Timer(0) < 100) { } is a lot harder than I had anticipated, so I'm punting on array-style setting of the various RCX source (such as Timer(), UpperLimit(), etc). There are (...) (24 years ago, 13-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: NQC 2.x event processing
|
|
(...) Not really a stack problem, just a control flow issue. On suggestion for the event handling was something like this: begin_events(EVENT_MASK, event_handler); // put code that executes during event monitoring here end_events event_handler: // (...) (24 years ago, 10-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: NQC 2.x event processing
|
|
(...) #3, which was the approach you took. (...) I think what I liked about the approach in pBrick script was that it was fairly like coding a microcontroller in assembler: set up an interrupt vector and then include a label and code for the (...) (24 years ago, 5-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: communication brick <-> PC
|
|
(...) Cool. We'll wait patiently. :) (24 years ago, 4-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: communication brick <-> PC
|
|
(...) My current thoughts are to add "listen" support to rcxlib/RCX_Link, but not add anything else to the nqc tool itself. This would facilitate writing a small wrapper program around rcxlib/RCX_Link that could send/receive messages without (...) (24 years ago, 4-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: communication brick <-> PC
|
|
(...) It can be used, but the problem is that the tower shuts off fairly quickly if it doesn't hear anything from the computer. So the listening program would need to be sending keep-alive messages periodically. I think that Dave will put something (...) (24 years ago, 4-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | communication brick <-> PC
|
|
Hi there ! I've got a question concerning ir communication with the brick ... After having done some low-level debugging to make a self-written programm communicate with my brick using the IR tower, I'd like to make my programm control the brick. (...) (24 years ago, 4-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: NQC 2.x event processing
|
|
(...) I don't have any changes in mind for the monitor/catch construct, although I'll listen to suggestions if people have any. There was a brief discussion about this a while back: (URL) that point I was already pushing a procedural approach - (...) (24 years ago, 4-Jun-00, to lugnet.robotics.rcx.nqc)
|
| |
| | NQC 2.x event processing
|
|
Dave, I'm curious if the system of events and event-trapping in NQC 2.x will remain about the same as it is now. I played around with it this last week, and had little success (it worked once or twice, I *think*), but what struck me was how much I (...) (24 years ago, 4-Jun-00, to lugnet.robotics.rcx.nqc)
|
