Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Paul E. Bennett" Newsgroups: comp.lang.forth Subject: Re: OT: ANS Forth Followup-To: comp.lang.forth Date: Sat, 23 Feb 2013 09:15:06 +0000 Organization: Hidecs Consultancy Lines: 92 Message-ID: References: <6010e112-93d6-4541-9ba8-2dc4020eec0c@googlegroups.com> <20130219191650.21147.66122@Nokia-N810-43-7> <20130219214611.21680.52657@Nokia-N810-43-7> <51ef1ca5-e3de-42fd-acbd-289de46a90a6@googlegroups.com> <7xa9qx4lmi.fsf@ruckus.brouhaha.com> <7xehg7ph2g.fsf@ruckus.brouhaha.com> Reply-To: Paul_E.Bennett@topmail.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7Bit X-Trace: individual.net t3nXFEKaeBDlHNNXlCD9+QpqyKflwCv0VdKvJSL/mwg6Er/2leWd17lQlIAi3ATn8q Cancel-Lock: sha1:YA2v4OgWshVfCCrzYtY0Wdt4/P4= Mail-Copies-To: Paul_E.Bennett@topmail.co.uk User-Agent: KNode/0.99.01 Xref: csiph.com comp.lang.forth:19939 Paul Rubin wrote: > Disclosure: I've never worked on hard-real-time stuff, so maybe my > picture of this kind of coding is unrealistic. But I'd imagine using > some combination of: From one who has then... > 1) stopping the arm when it misbehaves, so that debugger inspection > happens with the arm not moving, and/or > > 2) using a simulator instead of the actual robot mechanism for debugging > the control software, to the extent possible, In a robotic application it is usual to have fully resolved all the motion issues before one lets the control system loose on the mechanical bit. This is usually done with an appropriate level of bench testing. So your number 2 option is often the more likely during development. However, if you notice problems after the control system and arm are coupled you take a trace of all the possible data you can grab and return to the simulator to try and re-produce it there. Of course, not all hard real-time issues are to do with robotics. Sensing activities for which one needs to raise alarms in order to preserve life are extremely hard real-time issues. Getting a very time dependent series of readings from sensors and ensuring that all values are within the right zone at the right timing is an extremely vexing task and only running code at full speed and tracing the data streams will do (experience from a medical device project). > 3) modelling the entire system in something like Matlab before even > messing with the physical robot or with fixed-point Forth code. That > gives you something to compare your Forth program's behavior against. Yes. I quite often use a simple spreadsheet for such tasks as well. >> If you need to know the value of Y you can just look at it; if it's >> changing rapidly you need a trace. > > OK, you've got a trace: you've recorded all the sensor readings and > motor signals while the arm was running, including when it started > misbehaving after some particular motions. Your Forth algorithm's > output are reasonably close to the more precise Matlab output over most > of the test, but they go seriously wrong at a particular place. So now > you've got a misbehaving, serial numerical algorithm to debug, > completely separated from the realtime aspect. It is crunching a bunch > of numbers and going wrong someplace. You can "chunk-run" the code by inserting a ".S KEY DROP" sequence into suitable places in the code. This allows most of the code to run at full speed but gives you points at which you have a bunch of stacked data values available to examine before you step on for the next chunk. Even with the code running the real machine this sort of thing still assists in finding the reasons for weird motions (even if they are actually mechanical in nature). > Unless the calculation was horribly complex, I'd tend to approach that > sort of problem by single stepping the program and observing the > intermediate results until I saw something go wrong. The most complex calculations are always reducible to a series of smaller and much simpler ones. Those issues are the ones to be rid of before attaching to the machine. Hence the bench-test and simulator run requirements. > Another place where I find single stepping incredibly useful is in just > understanding what a big unfamiliar piece of code is doing. E.g. the > program is building a certain output and I can see where the result > becomes available, and I have to add a feature somewhere before that. > How did the output get to be what it is? I send in some input, > and start single stepping, observing, interacting, exploring. If this is from the perspective of having code and no source, then I will agree that single stepping the machine can help but it can also hinder in so many ways, especially with interrupts coming in that need quick responses. > The old Lisp Machine environments were fantastically good at this sort > of thing, one reason I regret never having used them. It sounds very > much in the spirit of Forth as well, so I'm really surprised that the > Forthers here aren't embracing it. We have our ways. -- ******************************************************************** Paul E. Bennett............... Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************