Shop OBEX P1 Docs P2 Docs Learn Events
Propforth v5.5 is available for download - Page 3 — Parallax Forums

Propforth v5.5 is available for download

1356726

Comments

  • mindrobotsmindrobots Posts: 6,506
    edited 2013-05-05 09:59
    J ? what the heck? Great, another language!!

    The flow control serial I/O sounds like a good addition.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-05 16:18
    mindrobots wrote: »
    J ? what the heck? Great, another language!!

    The flow control serial I/O sounds like a good addition.


    that's what i said. Sal is big on "the right tool for the right job" but understands that us regular folk might perfer to stick to one or two of the more popular options. Python is what we thought would fit, he will convert his proof of concept to python if we don't select another option.

    The PC side could be anything, as long as we implemement the flow control properly, which i believe he with specify.

    Sal will also dig out his "massivive logging" example, which might be part of the new package.
  • iammegatroniammegatron Posts: 40
    edited 2013-05-06 10:46
    In my opinion, J is a lot like forth. It stacks up operators (more mathematical operators in J). For example, in J, the "average" function can be defined as: ( +/ % #)

    that is (sum divide tally)

    It would be cool to see propforth and J working together.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-07 07:46
    LittleRobot pilot session: We broke one of our assistants.

    The kid (30) we hired as teaching assistant resigned. He was bright, enthusiastic, good with kids, and had experience with other kids' robotics programs. But something did not click with the propforth program. While some of the cause may have been poor infrastructure (his old laptop could not run google video chat for remote support during lab sessions, etc), the feedback was the the materials were "too insider and filled with jargon". The intent was for the instructors to point these issues out, so that I could address them, but we never got that far. Conclusion is the material is just overwhelming for some folks.

    Luckily, the other assistant is doing better. In fact, she has done all the exercises just as the kids have done (Hello Word and Blinky LED), and has had no problems. We asked her to burn the EEprom on a Quickstart; she was done in about 5 minutes. When we asked her to do the rest, she already had :). Conclusion is the material MIGHT BE just fine for some folks.

    The regular teachers had pointed out that some of the kids (two in particular) which are normally very quiet (and bored?) are bouncing around and loving the team programming. I don't know if this material will work on ANY kid, but is does seem to work with the hand picked group in the pilot.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-12 12:32
    Todays's Call: Logging and Documentation

    - Few Read the documentaion
    - Logging to microsecond with minimal drift

    Documentation: Nobody Reads it? This is problematic. Its often too expensive to hire skilled professional writers and editors, so the stuff we tend to see frequentily is poor (too poor to bother reading?). So "nobody reads it" and so "nobody bothers to write it". And/or some folks just think different; the material that works for me doesn't work for somebody else, etc. Looking for ideas on how to approach this. In particular, how to train KIDS to read the material first, or at least know the material exists and determine when its worhwhile to spend the time reading.

    LOGGING: I finally have a task that justifies learning about logging. When it rains, the sump pump cycles more frequently; if its going to fail, it will probably fail at the worst possible time, when its raining. I need to log when the system cycles, and predict the number of cycles until failure, and the calender time until failure. The goal is to change the part before is fails, but not sooner than necessary.

    Sal brought out the "Logging To SD" package. Sal has been using the logging package for over a year, but didn't think anyone else would have a use for it. He's funny. :) To be clear, this is precision logging without the need for a real time clock part. This is just using the stock prop and software (and an SD card for the log file)

    The time portion is microsecond (millionth of a second) since January 1, 1970. Logging works off the counter and 64 bit double math, using 128 bit intermediate values as needed. The intermediate values don't matter to us, they are handled internally.

    To set up, we load some source code files to the prop, for autoboot, double math, and time handling. We also create a file bigger than we will need to hold the log. The log file can be up to the size available on the SD. On Sal's 4 Gig card, the largest file he logged was 15 meg. This was a couple days at about one record per second.

    When the prop is started, propforth loads necessary definitions from SD, and begins logging. The default time comes up as Noon January 1, 1970. We manually set th clock to some know time, clear the log, and let it run.

    DRIFT: There is some drift in the prop crystal. After a day or so, we check the drift, enter a correction factor (ticks per day or something) and the clock is spot on after that, as long as the temperature doesn't change. The observation is the one in the house does not drift, the one in the garage does drift. Over the courrse of a day, the garage test unit drifts out then drifts back according to temperature, I guess if it was calibrated as sunrise or sunset it would be closest. Over the course of a year, the same, maybe calibrate it at spring and at fall and over the course of the year it would average out. Sal figures we could use a termistor and dynamically correct for temperature drift, but is hasn't been necessary yet. And, the unit in the house is nuts dead on after around a year.

    Time stamp collisions: There is the possibility of time stamp collisions. At microsecond resolution, Sal has not seen any yet. Even with a bunch of cogs doing stuff, he has not encountered two time stamps with the same number. There's enough microseconds so multiple loggin events don't happen at the same time, collisions are not likely. Neat-o!

    Overruns: It can't log more frequently than the time it takes to write to the log. For example, if we log every 10 milliseconds, and sometimes it takes 12 milliseconds to write to the log (he didn't have the exact number), and overrun will occur. Ther will be a bunch of records every 10 milliseconds, when the 12 millisecond event happens there will be a gap of 56 SECONDS (using using a 5Mz crystal running an 80 Mz clock) till the counter rolls over. So, the rule of thumb is log less often that the write time.

    Large Data: It take a long time to pull data off the prop SD, about 10 minutes for 15 meg. Recall that the prop SD is considered internal to the prop, we can't just pop it in the PC and read it like we can with a FAT formatted SD. So the rule of thmb is log less than once a second if we are going to log for an extended period of time (days or weeks).

    BUFFERING: This will be part two of logging, Sal is keeping it separate for now so my head does not explode.
    Records can be of any size, the example allot's 255 bytes. SD cards have a finite write speed, and limited number of write cycles, particularly the cheaper ones. So a cog is set up to buffer a whole bunch of records, and write these all at once as a single write operation. This can also be used to capture records faster, when many records are collected in a single SD write period. Nifty!

    Processing: Sal processes the log data on the PC using J. If I understand correctly, the J program parsed and crunched the 15 meg
    (over 16000 records?) in less than half a second. He pressed the enter key and the answer popped up. Bing! The J code looks even stranger than forth, but its "easy if one reads the documentation". At least if you're Sal :).

    It will take a while for me to get my head around all this, and write it up. I also has the LittleRobot pilot as a priority, so that comes first. When the logging material is ready, it will be posted as an extension, and later included in a release.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-12 12:57
    Since I know you're going to ask:

    The J program on the PC calculated variance in time stamps.

    The test data was the counter, the local time (curent time zone) , and the unix time (UTC).

    When the three data items were collected first, then formatted, the variance was very consistent.

    When each data items was collected and then formated before moving on to the next data item, there was a more interesting variance. Formatting takes longer for items with more characters. The variance was from 800 to 1200 microseconds over the 15 meg file. OK, its boring but its just an example.

    J was used because it was the solution that worked. It parsed and crunched 15 meg of data (over 16000 records) in the same time as hitting a cariage return. Compare with Excel, which choked after 8000 records. Excel could not parse the data, and so could not process it. Nothing against Excel, it just could not handle this particular data set.

    Neat! If I eve get time, I might look into J.
  • caskazcaskaz Posts: 957
    edited 2013-05-17 00:31
    Hi prof_braino.

    I'm looking for forth-source-code for _eeread and _eewrite.
    They are not on StartKernel-1.f and StartKernel-2.f and DevKernel.f.

    Where are they?
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-17 06:39
    caskaz wrote: »
    Hi prof_braino.

    I'm looking for forth-source-code for _eeread and _eewrite.
    They are not on StartKernel-1.f and StartKernel-2.f and DevKernel.f.

    Where are they?

    I'm not sure but I will make a couple guesses:

    I think this might be a kernel thing, as we noticed when Loopy was looking at the serial driver. Some parts get optimized in assembler and integrated into the kernel. As more integrations and optimizations take place, the details of deeply integrated function can get lost. For example the serial driver is hard to separate from the interpreter, modifying one would break the other, unless one REALLY know what's going on (and if we have to ask, we don't). When a new kernel version is generated using the `makeforth` word it only takes the current definition, and looses the unused portions, which includes comments, since comments are ignored by the interpreter. The original source for all words was forth, and this was included with the code when it was FIRST optimized. But some of the changes are not in our version of the docs; Sal didn't always include the pre-optimized code as he does now; the notes might be only on Sal's development archive. SO, we would have to look in the version that introduced the EEprom material, that would at least be a start. I don't remember which version introduced EEprom support, it might be 3.2 or 2.7. So that's one possibility.

    The other possibility is that we could find it in the build process. The propforth kernel always starts with the slow un-optimized forth-only kernel. The build and test automation builds this and runs the test suite. Then the automation works its way up to building the optimized kernels. At the point where it builds the EEprom kernel, it has used some file that has the EEprom definitions. I don't know if these would be in forth or assembler. It might be buried in those long string of base 64 code of pre-optimized assembler. I tired to look through the build process and the source modules when we were looking for the serial support, but I couldn't keep up, and could not document it properly. Since you are good at assembler, you might be able to, but you would probably need the hardware test bed set up to show that the build and test automation is running correctly.

    So if you can't easily find the source, it might be easier just to ask Sal. Consider opening an issue stating what you are looking for, what your final goal is. Now that the kernel is "finished" it might be time start documenting the deep dark secrets of the kernel internals.
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-05-17 06:47
    I need to make a new word index like this one for the latest release. I'll try and do that by the time the weekend is over if I have any downtime.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-17 06:56
    mindrobots wrote: »
    I need to make a new word index like this one for the latest release. I'll try and do that by the time the weekend is over if I have any downtime.

    Can you also include the *.spin files in your list? It looks like COG! and COG@ are only defined in the SPIN files, it looks like _eeread and _eewrite might be the same.

    The words that are only defined in spin would be the list for Sal and I to start documenting.

    We it be OK to ask for a comparison between your list and the output from `words`?
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-05-17 07:41
    Dude! You'll have to talk to the Change Management Group for stuff like that!! :lol:

    (Assuming I find the program that did this - I think it's a Python script on my Windows laptop) I'll try and include the Spin stuff....and I guess, compare the two outputs. Pray for rain in Medina this weekend or it won't happen!! :smile:
  • caskazcaskaz Posts: 957
    edited 2013-05-17 22:33
    Hi.

    I tested DRV8830(motor driver with i2C).
    Motor finely rotated.

    But strange phenominon occured.
    When word"reboot", QuickStart board stopped.
    Although pushing reset button, Cannot reset.
    Solution are 2type;
    1. When removed scl/sda and re-connect between TeraTerm and QS, PropForth start to operate.
    2. When removed Vcc or GND line for DRV8830 and re-connect between TeraTerm and QS, PropForth start to operate.
    I have no idea.
    640 x 480 - 312K
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-18 09:36
    caskaz wrote: »
    I tested DRV8830(motor driver with i2C).

    Excellent! This might be a nice upgrade for a littlerobot!
    But strange phenominon occured. When word"reboot", QuickStart board stopped.

    Could this be related to sharing SDA and SCL with EEPROM?
  • caskazcaskaz Posts: 957
    edited 2013-05-18 22:08
    Updated DRV8830 driver.

    Problem about reboot is caused by pull-up-resistor for SDA/SCL.
    Pull-up-resistor for QS(also other prop-board) are 10k-ohm.
    Firstly, I added 10k-ohm on SDA/SCL. (sum-resistor is 5k-ohm)
    Communication between QS and DRV8830 is ok. But when reboot, communication broke.

    Secondly, I added 1k-ohm on SDA/SCL. (sum-resistor is 909-ohm)
    Reboot is finely operate.

    Actually bigger than 1k(10k-ohm > R > 1k-ohm) might be ok.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-19 10:09
    caskaz wrote: »
    Hi prof_braino.

    I'm looking for forth-source-code for _eeread and _eewrite.
    They are not on StartKernel-1.f and StartKernel-2.f and DevKernel.f.

    Where are they?

    @Caskaz:

    Here's the path to get to the source code for the words _eeread and _eewrite:
    in v5.5/2013FEB23mygo V5.5 RC1.zip
    in /mygo/V5.5/kernels/InitEEpromkernel.bat
    see the file MAKE/scripts/InitEEprom.txt
    see MAKE/src/optimize/fs/fsrd.f
    see MAKE/src/optimize/fs/fswr.f

    All this finally points to
    /mygo/V5.5/kernels/MAKE/src/optimize/
    at files
    BootOptimizeAsmSrc-1.f
    and
    BootOptimizeAsmSrc-2.f

    All the source is generated by being built from scratch, every build.

    We removed the build automation from the top level paths as it was too confusing for beginners. Now the really interesting stuff is kind of buried in the mygo.zip. But its still all there, and is complete. In earlier releases some material would "fade away", this issue is now corrected.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-19 11:10
    Today's Call

    ANDROID GREEN
    LOGGING MODULE
    SD & LOGGING
    PF6
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-19 11:10
    ANDROID GREEN

    We are going to post the ANDROID app GREEN.apb. This is not the final form, and is never going to be supported, but its cool enough to play with. Its just a teaser for the real app which will be later. And I need it for LittleRobot class.

    GREEN is an android app that talks to Propforth over bluetooth. Basically a touch screen interface to propforth. It queries propforth for a configuration file. This file tell GREEN how to set its buttons. Green displays these buttons on the touch screen, and they send scripts to propforth.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-19 11:11
    LOGGING

    The LOGGING MODULE being refined, I will post the preliminary code for LOGGING1 (simple) and LOGGING2 (includes QUEUES, and Fhead and Ftail, read the first and last 4k of the log file). This material is completely stable and usable as far as we can tell, but will not be "released" until PropForth 6.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-19 11:11
    SD and LOGGING

    Sal is doing the LOG to SD testing. Turns out that SD cards anecdotaly seem to perfom BETTER than spec. Sal is logging one record per second, in a half gig file. After six days, he's got 50 meg. He guestimates it will run upto 45 days. If it makes it that long, he'll do it again for 90 days. He checks it every day to see if it died yet. While it writes each record on the SD once, it re-wrrites the file header every time there is a write. So if anything is going to blow, it should be the file header record. We should get a pretty good number for maximum write opeerations for SD.

    Does anyone have any real numbers on SD failure?
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-19 11:12
    PF6

    Sal is ready to start talking about the design for PropForth 6. PropForth 6 is different in that it is designed to run on Prop1, Prop2, or ARM. The problem with ARM is that the tool chain is unpleasant. Propforth 6 is slated to contain LOGGING and the SERAIL with FLOW CONTROL (this is just flow control implementated in such a way that it actually works consistently).

    The biggest design change fo Prop 6 is the multitasking. Instead of eight separate threads, one per cog, Forth will be sliced across all cogs. This combines the advantages of forth software time slicing and hardware time slicing, and removes some of the drawbacks. As long as there are enough slices, events can be handled in a predictable manner. The cogs can be divided into pools, so the time critical stuff can have one pool, and the non critical stuff can be in a different pool. There can be as many pools as there are threads (I think). The scheme appears to scale linearly, if you add another cog, the pool increases by X amount of slices. It appears that adding physical processors works the same, just ensure a pool is on a single physical processor.

    The estimate is three months for a prototype PropForth6 on prop 1. The ARM version should be ready shortly after that, depending on tool chain joy. We might get word of an Alpha or Beta around then, but I'm thinking Fall is when we will have something to play with. The Prop2 version won't be available until Prop 2 is available, of course.

    The question is, can anyone use it? The Prop1 stuff (spinforth up to PF5) is simple, yet few folks work through it. The PF6 will be necessarilly more complex (not complicated, just complex), this must be taken into account when our application code is being wriitten, if we are to use this to its protential. Is this a useful direction for this effort?

    My thought is, there are at least some folks that can use PF5. While the userbase grows slowly, it still grows; and the rate increases. The main problem is the documentation. AS more folks with better authoring skill add to the documentation, it becomes easier for new folks to get going. PF6 sounds awesome to me, I think it should not be "dumbed down" just because I haven't spent the time to learn the assembler, and can't write about it well. The more interesting it is, the more folks will use it. I voted that we go for it, and aim for hardware timeslicing. Sal's elegant simplicity usually prevails, it just takes effort to work through and understand. And this can happen with time, eventually we ordinary users can find reason to "get around to it", and work through the deep stuff. So Sal will continue to share this tool with us. Maybe I'm just a hoarder of what I perceive to be ultra-high tech.
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-05-19 11:38
    @Caskaz:

    Here's the path to get to the source code for the words _eeread and _eewrite:
    in v5.5/2013FEB23mygo V5.5 RC1.zip
    in /mygo/V5.5/kernels/InitEEpromkernel.bat
    see the file MAKE/scripts/InitEEprom.txt
    see MAKE/src/optimize/fs/fsrd.f
    see MAKE/src/optimize/fs/fswr.f

    All this finally points to
    /mygo/V5.5/kernels/MAKE/src/optimize/
    at files
    BootOptimizeAsmSrc-1.f
    and
    BootOptimizeAsmSrc-2.f

    All the source is generated by being built from scratch, every build.

    We removed the build automation from the top level paths as it was too confusing for beginners. Now the really interesting stuff is kind of buried in the mygo.zip. But its still all there, and is complete. In earlier releases some material would "fade away", this issue is now corrected.

    I couldn't find the 'mygo' version of the .zip in this thread or on the google code site.

    Using all the .f files in the .zip file that is out there, I was able to build a new word index.

    Interestingly, due to the changes in the build process, it's missing a lot of the core words (they are presumably buried in the 'mygo' .zip)

    Anyway, here's what I have so far for a new word index.

    I'll work on it more when I get a copy of the 'mygo' .zip

    Once the listing utility is fully functional, I'll put it and the index list on the wiki. The current utility is written in Perl....I'm not man enough to do something like this in Forth.

    Comment and feedback always welcome!!
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-20 06:37
    mindrobots wrote: »
    I couldn't find the 'mygo' version of the .zip in this thread or on the google code site.

    Ok, this is the trade off. The material was re-organized for folks could easily get to the kernels they are going to use, and the trade off was the advanced material got put lower.

    Let me try to do this again, maybe my steps were off.

    Everything is in the download. http://code.google.com/p/propforth/downloads/detail?name=PropForth-V5.5-20130317.zip
    Download and extract. The root level directory in this archive is
    v5.5
    

    The advanced material is in the misc directory
    /V5.5/misc/
    
    In this directory is a file
    2013FEB23mygo V5.5 RC1.zip
    
    .
    This file 2013FEB23mygo V5.5 RC1.zip is the file that used to be the entire release in the past. This contains the all the build automation and tests.

    Copy 2013FEB23mygo V5.5 RC1.zip to a convenient location and exact it contents. This give you the directory
    mygo
    
    .
    Find
    /mygo/V5.5/kernels/MAKE/src/
    
    Here we find all the source. There is also a directoy optimize here, so
    /mygo/V5.5/kernels/MAKE/src/optimize
    
    is the location for BootOptimizeAsmSrc-1.f and BootOptimizeAsmSrc-2.f

    The directory tree looks a little weird at first, but when you follow the automation it is organized in a straightforward manner. Its not really complicated, but there is a lot of stuff that has to happen in the right order. Even so, I tend to avoid the automation once testing is complete.
  • caskazcaskaz Posts: 957
    edited 2013-05-21 00:54
    It's I2C-devices.

    Wii-nunchaku can operate.
    But this is incomplete.
    WORD"_eeread and _eewrite " for PF5.2/PF5.5 can't use on this code.
    I have no idea.
    Can someeone solve this problem?
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-05-22 08:54
    A new Index of Forth v5.5 words.

    Attached is the new index (forth_index_v_5_5.txt), the zipped source files it was created with (all the .f sources I could find in the release put into one big file) and the perl script, forth_word_source_index, that I used to create the index in case anyone wants to play at home.

    The perl script has had the extension changed to .txt for the forum. Just change it back to .pl for perl.

    It expects to find the source file directory here: C:\MyCode\PropForth\V5.5\SourceFiles - if you put it someplace else, just change line 10 in the script to reflect the new location (you need to escape "\" in windows paths with "\", so each "\" becomes "\\" in the perl script.

    I'll load all this to the Wiki when I get a chance.

    This begs to have much more done with it: a little web app where you can click on the word from the index page and display the codes snippet(s) that show how the word is defined.; a PC based Forth editor/terminal, dictionary manager; more?

    forth_index_v_5_5.txt
    forth_word_source_index.txt
    Forthv55_SourceFiles.zip
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-22 20:01
    mindrobots wrote: »
    A new Index of Forth v5.5 words....This begs to have much more done with it:

    This is a good start, thanks for your effort

    COG@ is defined in StartKernel-1.f but isn't a regular colon definition.
    \ COG@ ( addr -- n1 ) \ fetch 32 bit value at cog addr
    ' COG@ asmlabel COG@
    
  • caskazcaskaz Posts: 957
    edited 2013-05-25 20:31
    Hi.

    I had exercise about WORD"serial".
    I got BeagleBoneBlack(BBB)'s log by using "serial".

    If merely getting BBB's log, Not need to use propeller.
    Only needing PropPlug and USB-cable.
    {
    PropForth 5.5
    2013/05/26 11:43:42
    
    BeagleBoneBlack     Propeller
          J1-1(GND) ---  GND
          J1-4(RxD) ---  P0(TxD)
          J1-5(TxD) ---  P1(RxD)  
    }
    
    : term
    	over cognchan min ." Hit CTL-P to exit term, CTL-Q exit nest1 CTL-R exit nest2 ... CTL-exit nest9~h0D~h0A"
    	>r >r cogid 0 r> r> (iolink)
    	begin
    		key dup h10 =
    		if
    			drop -1
    		else
    			dup h11 h19 between
    			if
    				1-
    			then
    			emit 0
    		then
    	until
    	cogid iounlink
    ;
    
    : _snet
    	4 cogreset
    	h10 delms
    	\ pin 0 rx, pin 1 tx  d115200/4 = d28800
    	c" 0 1 d28800 serial" 4 cogx
    	h100 delms
    	1 4 sersetflags 
    	1 7 sersetflags 
    ;
    
    : resnet _snet h10 delms h4 0 term 0 7 sersetflags ;
    
    640 x 480 - 123K
    640 x 480 - 204K
  • caskazcaskaz Posts: 957
    edited 2013-05-26 05:16
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-26 09:44
    Today's Call

    Logger

    The logger stopped, due to a power failure. When power came back, the logger resumed logging. Sal had to reset the time (from the default 1990, January 1, 12:00 am) but it is easy to go back and correct the time stamps. The old 2 gig SD card has not failed after two weeks and 110 meg of data. Sal off loaded the data at 80meg, it took 6 hours over bluetooth. Sal is going to change it so it creates a new file each time the day rolls over, this this should not fail since each file has a new file header. Sal now has a mission to make a card fail, so he can understand the failure mode. He guestimates it should take about a year to test this properly.

    So far the variance in timestamps is 3-4 microseconds. If an application is concerned with microsecond accuracy, a temperature stablized crystal would be needed, but if we don't care about such accuracy, a stock crystal should be just fine. It just drifts in and out.

    NickRobotControl

    Sal really likes Nick Lordi's robot control language application for LittleRobot. "Its beautiful, very clear and concise, I can understand it in the time it takes to read it." This will be our example of well constructed forth code.

    LittleRobot

    We changed the BOM to use 2" pink foam for the chassis, and replaced the breadboard with Male to Female jumper wires. Boring a 1 inch hole in the pink foam leave a rough hole that the stepper motors can be press fitted into by hand. 1 inch #4 machine screws will be used to secure the steppers, but might not be necessary. All else will be fastened with velcro or duct tape or machine screws.

    The LittleRobot session 1 (pilot) is drawing to a close, session 2 (a workshop) is booked, and possible sessions 3 and 4 are in the process of getting booked.

    We haven't finallized the wheels. So far the options we've tried are laser cut acrylic wheels and 3D printed wheels. Laser cut wheels rely on kindness from someone with a laser cutter, and 3D printed wheels require lots of my time to run the printer. Maybe I need a big ol' box of 1/4 by 4 inch gears with 1/4 by 3/8 shaft holes from surplus.

    PROPFORTH 6

    Sal is building the optimized versions of PF6 now, on Prop 1, as a baseline for when Prop 2 comes out. Sal tested the synchronus serial drivers, sending 2 gig data over night, 11-12 bit times per character, about 20k chars per second. Compare to Bluetooth 4-5K char per second.

    The big difference of PropForth 6 is that it treats the cogs as a pool. Propforth 5 and below has one task per thread, and since most threads are idle most of the time, a lot of processing oportunities are wasted. Propforth 6 will distribute tasks over available cogs as needed. This should allow many more than 8 tasks one a single prop (provided we don't run out of other resources like code space). On the Prop2, with four threads per cog we will have 32 threads in our pool. This gives a large enough pool so that we can do many intermittant things at once (more than 32), and deterministic execution should be minimally impacted. This is going to be COOL!
  • max72max72 Posts: 1,155
    edited 2013-05-26 13:52
    I 3d printed some wheels for the stepper motors, and they didn't require a long time to print. Or maybe we don not agree about "lot of time" definition...
    If you have rubber o-rings you could have better grip. I used a soft pla for tires, but it is not soft enough.
    Pictures are here:
    http://forums.parallax.com/showthread.php/138125-Erco-s-Figure-Eight-Challenge?p=1157894&viewfull=1#post1157894
    The design is very simple, but in case you are interested I can post the model.
    You can thighten the hub with a couple of screws.
    Massimo
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-26 14:23
    max72 wrote: »
    I 3d printed some wheels for the stepper motors, and they didn't require a long time to print. Or maybe we don not agree about "lot of time" definition...
    Massimo

    Thanks for the response. Please post the model, more options is better.

    One set of wheels from

    http://code.google.com/p/propforth/downloads/detail?name=LittleRobot.scad

    only take a bout an hour, from "get coffee" to "put in box". Each group has 12 to 30 participants. If I could just sit and tend the machine, it wouldn't be an issue (I can sit and watch the machine for hours given the chance) but every time the kid cries, or the door bell or phone rings, or other interruption, there is the likelyhood of scrapping another piece. RepRap is not always the ideal choice for volume production. This remains the fall back, but I would prefer a less labor intensive (on my part) solution.

    The current printed wheels are such that #6 rubberbands fit and provide traction, its like a buck for a box of 100; OBC shipped what look like sections of bicycle inner tube with the acrylic wheels

    Ideally, the participants would come up with their own wheels, but none have so far .
Sign In or Register to comment.