LogoBot

[Damian Axford]

HI All

Following our kick-off discussion on Tues, and further design work last night - it seems time to give LogoBot it's own discussion thread(ta da) and it's own git repo:

https://github.com/snhack/LogoBot

I've added readme files to the structure to give you a glimpse of the future layout - we'll go over the point of all the directories/files next week.  For now, please put your vitamin models into the hardware/vitamins directory.

I'd also like to adopt a self-documenting convention - how does everyone feel about using doxygen?  anyone prefer an alternative?  (emphasis on simple)

PS - I went with an MIT license - feel free to propose an alternative, 3of6 rule applies :)

[Damian Axford]

Read a short post on the OpenSCAD git that suggested NaturalDocs might be easier to use and compatible with OpenSCAD source...

[Gyrobot]

Cannot edit the repo at work but the link to the Google group discussion is broken : "related Google Groups thread"

[Damian Axford]

smeg - must be a mistake in my markdown...  :)  will fix

[Damian Axford]

interesting... works ok from the git webpage for me?

[Gyrobot]

It now works for me too ;-o

As you were.

[Malcolm Pett]

Ok I know I have to put this on github but I am not sure when I will get time have major server issues today!

anyway here is my first try at the motor

https://www.dropbox.com/s/szpjiehxbq1xpcb/motor.scad?dl=0

(excuse dropbox)

I need to add in some more variable and i am not sure I have structured it correctly...but hey you live and learn...!

Mal

[Damian Axford]

@Steve - sweet

@Malcom - excellent and fast work! :)  my immediate thoughts are:

1) See if you can wrap this into a module

2) Try and add a flat to the motor shaft

3) Try to use a difference() function to punch holes through the fixing tabs

very nearly there...

[Jamie Osborne]

MIT license is good.

As expected for a github workflow, can I please ask that if you modify anybody else's work, please be polite and submit a pull request. :)

This doesn't apply to adding your own *new files* to this shared repo.

Jamie

--
You received this message because you are subscribed to the Google Groups "swindon-hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hacksp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jamie Osborne]

@malcom - I can't find you on github! Once you have access, would be great if you made commits before and after any feedback - so we can learn from the diffs. :)

P.S. Really looking forward to following the progress of this repo (as well as joining in!)

Jamie

--

[Damian Axford]

I've finished fleshing out the git repo...  please clone it and have a read through the various files.  If you open the hardware/LogoBot.scad file you should see an orange disc with a caster at the rear.  This is a placeholder ready for next week.

I've also created an example vitamin file (of the caster) for reference, as well as a bunch of other example code for us to work through next week.

:)

[Jamie Osborne]

As we were discussing the lack of documentation or autocompletion in OpenSCAD, I'd go with the one that's easiest for everyone to build (looks like NaturalDocs?) - so long as the OpenSCAD community doesn't have a different de facto system?

Jamie

On 16 Oct 2014, at 10:33, Damian Axford <dam...@axford.me.uk> wrote:

Read a short post on the OpenSCAD git that suggested NaturalDocs might be easier to use and compatible with OpenSCAD source...

[Jamie Osborne]

One thing I was thinking - is the main reason we were having a dome, was to have the big logobot that was Pi powered (and thus, needed more room anyway - breaking the mirobot design).

So, if the dome is a pain to print (and obviously can't be laser cut!) then we could leave that for now. Perhaps keep it in mind for an optional cover if wanted? (Might be more interesting to see the internals?)

Don't mind either way, but we got there based on other changes that don't apply to the mini logobots. :)

Jamie

--

[Damian Axford]

Documentation - there doesn't seem to be a community default, so lets go with NaturalDocs, at least for now

Dome - I'm fairly easy either way, but would like to play with adding domes to the little robots just to make them look cool :)  Plus I love the idea of having a range of interchangeable shells to personalise the robots, and/or feed into MeshMixer for making bonkers variants.

[Damian Axford]

@Malcolm - have added your file into the git repo...  located in:  hardware/vitamins/motor.scad

As per Jamie's comment - now we can watch as the file progresses :)

[Robert Longbottom]

Dome - so long as there are some mounting holes for the cover on the base plate and they are generically placed then I'd say go with the idea of interchangeable lids and then we could have a few options available.

On 16 October 2014 13:14:47 Damian Axford <dam...@axford.me.uk> wrote:

Documentation - there doesn't seem to be a community default, so lets go with NaturalDocs, at least for now

Dome - I'm fairly easy either way, but would like to play with adding domes to the little robots just to make them look cool :)  Plus I love the idea of having a range of interchangeable shells to personalise the robots, and/or feed into MeshMixer for making bonkers variants.

--

[Jamie Osborne]

Yup, interchangeable domes is cool.

We could sell the base kit without a dome - then for a small charge, attendees can choose to have a dome; either prefabbed (perhaps from a few choices), or with their own modifications!

Jamie

[Gyrobot]

A Conic is easier to print than a dome, because it's not less than 45deg, and would have added pen support higher up + give extra good internal volume.

Something like this :

http://www.thingiverse.com/thing:105561

The Reprap logo is also a 2D teardrop/drop shape. This could be a 3D version/inferring opensource, but that's probably too deep?

[Malcolm Pett]

Just signed up  Jamie malxpett 

On Thursday, 16 October 2014 10:23:31 UTC+1, Damian Axford wrote:

[Malcolm Pett]

Thanks Damia...something for the weekend!

Mal

On Thursday, 16 October 2014 10:23:31 UTC+1, Damian Axford wrote:

[Jamie Osborne]

Hmm, "These aren't the droids you're looking for"..

Is the bottom of that print not more dome shaped?

Jamie

--

[Gyrobot]

It's not a Weeble Wobble, it will fall down.

Flat bottomed, design to use an old CD/DVD as the base, see some of the other images, by swiping the picture right to left (on a phone).

[Jamie Osborne]

Cool, I've sent an invite. Let me/us know if you need any help!

While not needed just now, there are notes and links at the website repo on making pull requests (to either change a file that you didn't create, or that somebody else is likely working on), please let me know if you want a demo next week. :)

Jamie

--

[Jamie Osborne]

Ah yes, I couldn't see that there were any other pics on my phone. ;)

I thought it looked like a flat bottomed dome - that would still be doable wouldn't it?

Jamie

[Damian Axford]

@Jamie - Pull Requests - I think a session on how to manage pull requests (and associated branching, etc) is an excellent idea - if only so we all agree on best practises for this project.  I'd suggest we integrate this into the wk3 session, as that focuses more on the collaborative design side.

To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hackspace+unsubscribe@googlegroups.com.

[Jamie Osborne]

Ok, would you like me to run it and include a quick demo of the website fork/branch/build/pull request process. You could then wrap up with any bits that apply to OpenSCAD and documentation comments??

Jamie

[Robert Longbottom]

I've added a noddy nut and bolt library (with 2! types of bolt) and bolttest.scad that draws some different sizes using the library.  I haven't gone to town on exact sizes because I'm assuming that there are free libraries available (or Damian, you already have an all singing all dancing version) for these things and we can just use one of those.

Hellishly complex openscad setup with all those files, but I can see how its necessary and will work well for a larger model.  I like DebugCoordinateFrames, neat idea :-)  Haven't quite worked out what DebugConnectors does yet though...

Rob.

[Damian Axford]

sounds good - I think we're going to move through the course content faster than I had expected, so focusing on git and general collaboration in wk3 is a good plan.  Could you flesh out your agenda on the Wiki page for the OpenSCAD course under wk3...  then I can merge my bits around it

[Damian Axford]

@Rob - just had a look at your BoltLibrary...  looks v. good :)   Minor builds:

• Add color - I'd suggest using the global MetalColor variable
• Convert to NaturalDocs comments - see hardware/vitamins/PlasticCaster.scad for an example

If you're feeling super smug - take a look at the Connectors example in PlasticCaster and how it's used in hardware/assemblies/LogoBot.scad

If it makes sense, try applying the concept to your Bolt library. 

[Malcolm Pett]

@Jamie just added an update but couldn't overwrite the older one and forgot to put in a proper comment but for the life of me can not work out how to edit...

@Damian...Worked out how to use difference and mirror (for the shaft flanges and should probably change the bolt flanges as well ).

Now a module (function, sub...lol)

Just need to go over the dimensions and make sure it all is correct...may even print it to check..

Mal 

[Damian Axford]

@Mal - nice one :)

Everyone - I've posted a bunch more examples on various OpenSCAD features (like the ones we did last night) to the associated git repo:

https://github.com/snhack/OpenSCAD/tree/master/Extended%20Course/wk1%20-%20Intro%20to%20OpenSCAD

[jmeosbn .]

@malcom (this is getting confusing!) - if you can wait until wednesday (assuming nobody else needs your design before then - would be nice to track the design progress though) we can use your file as an example and I'll run through the whole process. :)

@damian Ok, if it's going to be the bulk of a workshop session, shall I just do a git workshop before you do yours on wednesday. We may even get some interest in the git that stay for opens cad or vice versa? Seems like it'll be needed by week 2 (if not before!)..

Jamie Osborne

--

[Damian Axford]

@Jamie - I think you're right.  Let's kickoff next week with a quick intro to git and then we can get stuck into peoples various design files.  Do you think you can cover the git stuff in <45min?  that'll leave plenty of time to work through OpenSCAD stuff.

[Malcolm Pett]

@Jamie - ok but I won't be there next Wednesday...at the moment I can only make it every other week. I am hoping someone will take notes :-) Do you want me to write something up about the design flow?

[jmeosbn .]

Do you want me to write something up about the design flow?

Re: tracking the design? I was referring to not seeing your commits to see what changes are made after feedback etc.

Shame you can't get here, as it'd be nice to get everything on github.. Can you send a screenshot of what you're having trouble with? From what you said earlier, it seems you're having trouble committing any changes to your earlier file posted by Damian - in which case you really could do with a primer on git and github. If you have an hour free on another evening, I could practice my workshop on you before Wednesday!

Jamie Osborne

[jmeosbn .]

Damian Axford <dam...@axford.me.uk> wrote:

 Do you think you can cover the git stuff in <45min?

If I skip the octopress install* and just cover making changes to the plain text source (not compiling the site - which I can just show on my machine).  I can then cover just enough to get going with pull requests, and cover some other git commands in a later session - perhaps splitting it into another pre-session the following week?

* I want to use the website repo as an example to encourage new posts!

Jamie Osborne

On Thu, Oct 16, 2014 at 4:38 PM, Damian Axford <dam...@axford.me.uk> wrote:

@Jamie - I think you're right.  Let's kickoff next week with a quick intro to git and then we can get stuck into peoples various design files.  Do you think you can cover the git stuff in <45min?  that'll leave plenty of time to work through OpenSCAD stuff.

--

[jmeosbn .]

Shall we get some rough start time for the double header workshops?  That way I can post some twitter thingies about them..

My current thinking for the next two wednesdays is two demi-workshop sessions (45 mins-ish) before your full size session (90 mins-ish). We don't start anything like this before 7pm - so that gives you a start time of 8pm at the earliest?  If you can't make my session - I'm sure you can follow my notes to confirm our workflows match up?

Jamie Osborne

[Damian Axford]

like it - agreed, and will try to make your session as I've mostly used git for personal projects, so am very rusty! :)

[Gyrobot]

I virtually have a web post ready to upload, if you want to use it as an example?

"How to 3D Print with Flexible Filaments"

[Malcolm Pett]

@Jamie- yep certainly could do with some help...I can probably spare an hour either over the weekend or on Tuesday night.

[Jamie Osborne]

Good call! Maybe make the pull request in advance - we can have it ready then with the little additions I do before pushing it live during the demo. :)

Jamie

> On 16 Oct 2014, at 18:12, Gyrobot <sp...@gyrobot.co.uk> wrote:
>
> I virtually have a web post ready to upload, if you want to use it as an example?
>
> "How to 3D Print with Flexible Filaments"
>

[jmeosbn .]

@malcom Great, I can make Tuesday evening, we can get your latest code committed then :)  usual time? (I'll check with Simon if the basement's free)

@damian Cool, how early can you make it? 7:30 is perhaps the latest we should start for 1.5 hours of workshopping.

Jamie Osborne

--

[jmeosbn .]

@Rob - did you say one of your hdmi -> vga leads *did work* with a Raspberry Pi? Planning to use the Pi with the projector but not really wanting to use composite.. :/

Jamie Osborne

[Damian Axford]

@Jamie - will aim for 7, but feel free to start without me and I'll play catchup.  

[jmeosbn .]

Cool, I'll put it up as 7pm and we'll prob spend 10 mins or so chatting and making tea.. :)

@malcom confirmed calendar is clear Tuesday, so we can run though some Github stuff from 6.30?

Jamie Osborne

On Thu, Oct 16, 2014 at 8:21 PM, Damian Axford <dam...@axford.me.uk> wrote:

@Jamie - will aim for 7, but feel free to start without me and I'll play catchup.  

--

[Robert Longbottom]

I've got a couple
 - hdmi -> dvi - pretty sure this works with the Pi.
 - hdmi -> vga - not sure, I think it might

I'll try and check them at the weekend if I get chance.

Rob.

[jmeosbn .]

Ah, please do - we can do dvi ok - but the damn projector is VGA!

Jamie Osborne

[Malcolm Pett]

Yeah ok I will be there for 6.30.

[Damian Axford]

Have added a load more content, comments and general goodness to the LogoBot repo.  Please sync your clones and take a look.  Most of the additions are prep work ready for the next 2 sessions, but you're welcome to get stuck in early and root around the code - hopefully it's fairly self-explanatory.

[castaway]

Created a pull request with the battery pack viramins

Jess

[jmeosbn .]

Hmm.. think I might have to get mine done over the weekend! (was planning to resurrect the LED Array project, but that can wait I think..)

Jamie Osborne

--

[Robert Longbottom]

Comitted ULN2003 stepper driver board - based on some guesswork from the top picture of one here: http://42bots.com/tutorials/28byj-48-stepper-motor-with-uln2003-driver-and-arduino-uno/

Note that there is a "nicer" driver board based on the ULN2803 (link on the wiki page) that is a single board that drives two steppers, but it doesn't seem anywhere near as common.  So possibly best to stick with having a driver board per stepper.  I think the latter approach is also cheaper.

Also claimed "LED" and committed on, because I needed some for the driver boards.

PS, didn't know github rendered stl's in the difference view!

Rob.

[Damian Axford]

@Jess - cool,  merged :)    Fancy adding the example usage into the sandbox? - there's a few examples in there already

@Rob - quick work and liking the coding style on the LED and driver board - what did you think of the naming conventions, etc?  anything you'd consider changing? 

@Jamie - yeah, come on - catchup :)

for those that have grasped the file structure already, feel free to submit pull requests for incorporating your vitamins into:

config/vitamins.scad

assemblies/LogoBot.scad

I put some comments in there to suggest where you might add them

.... and there's a chance I use too many smileys, ah well

[Jamie Osborne]

@Jamie - yeah, come on - catchup :)

Well, my LED is already done! Apparently.. ;)

I'll work on the Pi sled over the weekend and if there's a part left to do let me know?

Jamie

--

[Robert Longbottom]

Oh sorry I didn't know you were doing the led!  It was down as "?" on the list of who was doing what and I needs one, so I figured I might as well do it.

You're doing an arduino according to the the page.  Far more interesting than an led :-)

[Jamie Osborne]

That's ok - I should've been down for it, but was only joking! :)

Arduino? Hmm.. The Pro Mini though,  People seem to be simplifying the shapes so just a rectangle (with clearance for components) or do we need the holes? (I noticed you didn't include the LED legs)

I may do a 5mm LED (RGB and IR if legs needed)?

Jamie

[Damian Axford]

@Jamie - my bad - couldn't remember what everyone had said yes to...    ah well, an arduino vitamin would be great :)

your choice on which model, although I got the impression you were leaning towards the micro because of the USB port?  

In terms of model details, it's entirely up to you how much detail you put in, but I would aim for:

• Block for the circuit board
• Block out the large/important components (like the USB port and reset button)
• Include pins
• Include mounting holes - in case we end up using them

On Friday, 17 October 2014 23:32:32 UTC+1, jmeosbn wrote:

That's ok - I should've been down for it, but was only joking! :)

Arduino? Hmm.. The Pro Mini though,  People seem to be simplifying the shapes so just a rectangle (with clearance for components) or do we need the holes? (I noticed you didn't include the LED legs)

I may do a 5mm LED (RGB and IR if legs needed)?

Jamie

On 17 Oct 2014, at 22:59, Robert Longbottom <Robe...@iname.com> wrote:

Oh sorry I didn't know you were doing the led!  It was down as "?" on the list of who was doing what and I needs one, so I figured I might as well do it.

You're doing an arduino according to the the page.  Far more interesting than an led :-)

On 17 October 2014 22:50:49 Jamie Osborne <jme...@gmail.com> wrote:

@Jamie - yeah, come on - catchup :)

Well, my LED is already done! Apparently.. ;)

I'll work on the Pi sled over the weekend and if there's a part left to do let me know?

Jamie

On 17 Oct 2014, at 22:23, Damian Axford <dam...@axford.me.uk> wrote:

@Jess - cool,  merged :)    Fancy adding the example usage into the sandbox? - there's a few examples in there already

@Rob - quick work and liking the coding style on the LED and driver board - what did you think of the naming conventions, etc?  anything you'd consider changing? 

@Jamie - yeah, come on - catchup :)

for those that have grasped the file structure already, feel free to submit pull requests for incorporating your vitamins into:

config/vitamins.scad

assemblies/LogoBot.scad

I put some comments in there to suggest where you might add them

.... and there's a chance I use too many smileys, ah well

--
You received this message because you are subscribed to the Google Groups "swindon-hackspace" group.

To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hackspace+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "swindon-hackspace" group.

To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hackspace+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "swindon-hackspace" group.

To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hackspace+unsubscribe@googlegroups.com.

[Jamie Osborne]

No worries.

Yea, I'll need to price it up, but prob micro if the cost + USB cable works out not much more expensive.  I think the only real physical difference is a the USB micro socket instead of 6 pin header.

Jamie

To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hacksp...@googlegroups.com.

[Jess Robinson]

Added, another pull req :)

Jess

--
You received this message because you are subscribed to the Google Groups "swindon-hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hacksp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Using Opera's mail client: http://www.opera.com/mail/

[Malcolm Pett]

Thinking about it I have another small driver board that can drive a number of motors steppers and servos but at around £5 maybe to expensive.

http://www.ebay.co.uk/itm/L293D-Motor-Drive-Shield-Expansion-Board-Module-for-Arduino-Duemilanove-Mega-UNO-/251188057357?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item3a7bf9950d

Mal

[Damian Axford]

@Jess - merged :)  are you going to model the battery positive terminal and add colour?  <nudge nudge>

@Mal - aside from cost, it's also not that easy to mate to an arduino micro/pro mini...   

[Damian Axford]

All - when you're comfortable your part is done (or at least functional), it's worth printing a test piece to check mounting holes, exterior dimensions, etc line up with the real life object.

For example - I've added an example Marble Caster vitamin/assembly, but wanted to test the push connector would work correctly.  So I made a quick test plate (to mimic the robot base), then printed both to test the fit.  Turns out I need to adjust the push fit connector a little.

I'd keep the test plates as simple as possible - just enough to verify your dimensions are accurate.  This will avoid minor issues creeping into the main build.  The sandbox is a good place to put these test plates, and exported STL should go in the hardware/stl directory.

[Malcolm Pett]

Hmm should have thought about that!

[Robert Longbottom]

I pretty much looked at what you'd done in terms of naming and following that.  Must admit I had to change by bracketing the the 'C'-style rather than my usual C# style, but I'm not that fussed either way on that.  We just need to pick a style and use it.  I was assuming that if you already have some useful library functions then they would be in your coding style and so it would be easier to adapt to that than to edit a load of library functions.  So long as there _is_ a (reasonable) coding style thats what matters.

The only thing that slightly turns my stomach is the boiler plate comments, they seem very repetitive and most don't add much value in my view.  Local frame is useful, and a brief description of what a part is.  But the others...  nah.
- Author? yeah, I can look in the vcs log to find that out;
- parameters? it should be fairly clear from their name what they do, only really needed if it needs clarification and then maybe you need to rethink the paramters?;
- returns? again, shouldn't it be clear from the name of module or file or the description?

I realise it's probably necessary for the auto generated documentation, but I don't have a particularly high opinion of auto-generated documentation either (in most cases).  It tends to be repetitive boiler plate stuff that doesn't give much insight into the purpose of things.  Odd, I wonder why... :-)  But writing good documentation is hard!

[Robert Longbottom]

I've been playing with the OctoPrint timelapse features - here's the stepper driver board being printed (not sure it needs to be printed, but it's an excuse to do a timelapse)

https://www.youtube.com/watch?v=dCbS5-06dMg

[Jamie Osborne]

Hi all,

I’ve just pushed two branches to LogoBot: one is labeled promicro_vitamin, for which I’d like any comments on general style/layout/etc., but mainly I’m interested in some help on the other promicro_vitamin_no_workie branch.  While I ended up going with a more elegant solution, I still don’t know why the for loop gives unwanted results.

In order to not make the count and placement of holes rely on a “magic number”, I iterate on the pcbLength - 1 * holeSpace (for the serial header/micro USB port) - 2 * holeInset (the amount the pins are from edge of board) to give a number of holes to subtract.

Despite rowcount appearing to be an integer of 11 as expected (and does echo to 11), the for loop never reaches 11. If I set it manually to 11, it works. If I increase board length to 1.6 (inches) or greater, it also works.

I considered that the range may not be inclusive as in some languages This would seem to be a float->integer issue, but it does seem to calculate the correct value. In C, you can normally avoid integer math, by including a float, but these already use floats, and using holeInset*1 does calculate 11.5 as expected, and loop for 0..11.

holeSpace = 2.54;         // The spacing of the holes in mm = 2.54
holeInset = holeSpace/2;  // The spacing of the holes in mm = 1.27
pcbLength =  1.3 * 25.4;  // The length of the PCB in mm = 33.02
pcbWidth  =  0.7 * 25.4;  // The width of the PCB in mm = 17.78

rowpitch=pcbWidth-holeInset*2 = 15.24
rowcount=((pcbLength-holeSpace-holeInset*2)/holeSpace) = 11

I’ve since used a range with increment to iterate over the board length directly, which seems to give solid results - but I’d still like to know why the above doesn’t work?!

Regards,

Jamie Osborne

[Gyrobot]

I have also added MicroSwitch.scad too.

Homework done, now to buy an apple for the teacher.

[Damian Axford]

@Rob

Cool - and although I've collected/made a bunch of libraries, there's very a distinct lack of consistent style across them.  However, as this is a collab project, I thought it was worth setting a clear style so that we can at least keep our project internally consistent.   

Totally agree on the boiler plate code - PITA, and not something I'd usually bother with, but seemed appropriate if auto-generating documentation.  Perhaps we can make the call next week as to whether we collectively care enough to bother.... I'm not that fussed.  The only bits I'd like to keep are local frame and parameter descriptions, as parameter types can get confusing with OpenSCAD.

@Jamie

Good work.  I had a look at the no-workie version, no idea why that's not working, but resolved it with the addition of a round function:

rowcount=round((pcbLength-holeSpace-holeInset*2)/holeSpace);

No reason for it, but there must be some tiny rounding error creeping in, that is too small to see in the echo statement (as it is essentially showing a fixed number of floating point digits).

In terms of coding style - the only suggestion I'd have is to rethink your naming of global variables.  They are truly global in OpenSCAD, and things like holeDiam are way too generic.  Normally I'd prefix any global variables with the module name (e.g. ProMicro_xxxx ).  I'd also try and keep variables as local as you can, so if holeDiam is only used in a single module, declare it there, rather than have too many globals.

@Steve 

Cox's please :)  and will take a peek in a sec...

[jmeosbn .]

Ah, yes - I started to do that in Micro_USB_Clearance and for module names ArduinoPro_PCB, but hadn’t thought to go back and sort the others! I also thought it was some weird rounding like 10.9999999 or something - but as you say, it did seem to be an integer. Anyway - the other method seems more elegant and robust!

I’ve just put a pull request in, feel free to leave that until I sought those variables. I would like any thoughts on the blocking out of the board clearance and usb port though. :)

@steve and @damian - I prefer a “Pink Lady”; which I’m about to have - though I’m not sure if that’s just because it sounds rude, or that they are delicious!

Jamie Osborne

[Damian Axford]

@Steve

Nice model :)   Have added a wrapper to the sandbox for convenience.

Thoughts on coding style:

• UpperCamelCase the module names
• Impressive number of parameters ! :)  
• Prefixing parameters/local variables (e.g. ms_length) makes the code very explicit, but shouldn't be necessary - there should never be anything as generic as "length" declared globally that would conflict.  Losing the prefix saves a bunch of typing.
• Forcing high resolution circles (through $fn) in very small parts makes them look lovely in isolation, but will cause OpenSCAD to run like a dog with complex models.  We could permit this sort of detail with a global "resolution" parameter - set it to "dev" for low res or "production" for high res parts - something to debate Wed perhaps?

[Damian Axford]

@Jamie

The USB and clearance blocking look good to me - I like the transparent clearance bit - neat solution.  

Will leave merging until you've tweaked the variable names.

...and lol

[Robert Longbottom]

From a purely selfish point of view I think setting $fn to high values in modules should be avoided because my poor old laptop really doesn't like rotating openscad models rendered with F5 and rendering with F6 takes way too long (but at least then I can rotate the view)!  I'd say the only reason to set $fn other than globally should be if you want a triangle, pentagon, hexagon, etc.

[jmeosbn .]

Just pushed commit with naming changes (I think Github still doesn't notify of new commits to a pull request?).

Please note filename change; is it worth adding the headers as well?

Jamie Osborne

[jmeosbn .]

Forgot to ask about preferred style; since a lot of the functions act as compound statements, and adding braces for each one becomes silly - as does indenting each line - what is the preferred formatting for something like:

  color(colour)
    translate([move_x, move_y, move_z])
      linear_extrude(height=height)
        square(size = area, center = true);

which does show the intent(/indent?)

  color(colour)
    translate([move_x, move_y, move_z])
    linear_extrude(height=height)
    square(size = area, center = true);

This is more tidy, and is what I’ve used, but it’s a lie.

  color(colour) translate([move_x, move_y, move_z])
    linear_extrude(height=height) square(size = area, center = true);

I considered this, but again: ambiguous and the second statements could be missed

  color(colour) {
    translate([move_x, move_y, move_z]) {
       linear_extrude(height=height) {
         square(size = area, center = true);
      }
    }
  }

More explicit, but very verbose when one line chained/compounds are so common here..

Jamie Osborne

[Damian Axford]

@Jamie - merged.  Looking good

As to indenting style, I favour this one:

color(colour) translate([move_x, move_y, move_z]) linear_extrude(height=height) square(size = area, center = true);

It's a mild compromise, but does the job of making the code readable without involving too much typing or needing a widescreen to read it.

[Damian Axford]

A further thought on function and variable naming...    I favour Java style (CamelCase), but there are many libraries out there that favour Perl style (this_is_my_variable).  Either works fine, and is readable, but it does get confusing when both styles are used.  

From the initial wave of vitamins, it's clear we've got fans of both styles in the group....   so, should we:

a) All converge on a single style?  and if so, which - democratic vote?

b) Accept both styles and live in glorious harmony

c) Not care, because it's no big deal (which is really option b in disguise)

:)

PS - I vote (a), but could be swayed by something sugary, like a muffin, or something boring, like a vote.... if i was voting, it would be for the muffin...

[Robert Longbottom]

I think it would be best to agree on a single style if possible.  Else two people working on the same thing in the same file might use different standards, mayhem would ensue, and the world might stop turning.

I'd favour the CamelCase style too because its closest to what I do day in day out.  But I'm not that fussed either way.

--

[Gyrobot]

I am not a fan of either so I am prepared to be bullied into the most popular.

It's such a shame that openSCAD doesn't write the code itself to the correct standard by the user pressing icons and filling dialog boxes in,,, no wait that would be realCAD ;-)

;-)

[Jamie Osborne]

I don't mind too much and had just looked at the existing code to see what was being used. I think I mainly came away with PascalCase / InterCapped for module prefixed with ModulePrefix_Module_Or_Global_Varand var or my_local_var.

This is only what I gleaned though (I think MicroServo uses this IIRC) and isn't my particular preference one way or another. :)

Jamie

--

[Damian Axford]

CamelCase creeping into the lead...  let's conclude on Wed, but I suspect we have a winner

To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hackspace+unsubscribe@googlegroups.com.

[Jamie Osborne]

In case you do want a vote, my prefs:

PascalCase - for global vars and modules, underscores optional between words after the common prefix.

camelCase for compound names of local vars.

camelCase if there's an analogue to a C function in comparison to a class - or perhaps lowercase_with_underscores.

Jamie

[Jamie Osborne]

I refer to that as PascalCase in contrast to camelCase - but yes, seems to be favoured in the existing code. :)

Jamie

To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hacksp...@googlegroups.com.

[Jess Robinson]

How about home made Lebkuchen?

Jess

--
You received this message because you are subscribed to a topic in the Google Groups "swindon-hackspace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swindon-hackspace/0EO_l_R9aW0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swindon-hacksp...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Gyrobot]

Never heard of that as a coding style, but I like the flavour of it..

[jmeosbn .]

Is there any preference (or dis/advantages) to using cubes and cylinders, etc., over extruded squares and circles?

In FreeCAD these are treated differently (in a way I don't quite understand), but it seems the former would be much tidier?

Jamie Osborne

--

You received this message because you are subscribed to the Google Groups "swindon-hackspace" group.

To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hacksp...@googlegroups.com.

[Damian Axford]

General guidelines:

• If you're doing boolean operations on them that lie in a single plane, then start from 2D primitives and extrude
• If only doing simple stuff (unions), or nothing at all, then go with 3D primitives

Extruding is a very cheap/fast operation, it's booleans, hulls and minkowski that are slow - and all them are way faster in 2D than 3D.

[Damian Axford]

Have added another vitamin (Breadboard) to demonstrate some more sophisticated techniques for dealing with pre-defined collections of parameterised vitamins.  Headlines:

• Using array constants to store parameters for vitamin types
• Using functions as "type getters"
• Using functions  as "connector getters"

This is particularly relevant where a vitamin library needs to model a set of similar parts (Arduino, MicroSwitch, etc)

[Malcolm Pett]

Sorry been really busy at work lost 2 servers on Thursday and all back-ups!

@Jamie we still on for tonight? Around 6.30 ish?

[Jamie Osborne]

Yup! I'll either wait upstairs or leave the bell on the door. :)

Jamie

--

[Gyrobot]

With reference to vitamins and openSCAD speed.

Do we actually call these modules up? 

Or do we just use them as parametric stl creators?

I would have thought it is quicker for openSCAD to import many bolt stls and micro-switch stls etc than to call each module up where used and OpenSCAD has to render each one individually, by running through the CSG tree of each vitamin.

Has anyone tried this as a speed test, if not maybe tomorrow?

Too many questions? (Ooops there's another)

[Damian Axford]

You are correct on speed - it's faster for OpenSCAD to load raw STL than it is to render complex parts... however, when you're in active development, it's easier to work with the source modules.

I'm sure we could establish a programming convention/pattern for switching to STL once a part is finalised... will have a ponder on how best to do this.  

I've also had some lunchtime fun with setting out some automation of assembly views for use in the Assembly Guide.  Check this out for an example of the end result - this will form part of the wk4 lesson:

https://github.com/snhack/LogoBot/blob/master/hardware/AssemblyGuide.md

[Gyrobot]

Hey, that's not fair, how come you can render the base plate and marble caster with a high $fn eehh eh eh????

[Damian Axford]

cos I'm special - innit :)

... and have prototyped an STL swap-out within assembles/LogoBot.scad and assemblies/MarbleCaster.scad

it relies on pre-generation of the STL, either manually or using stls.py

this is really stuff to discuss/debate wk4, but it's fun

[Damian Axford]

as a follow-on....  STL files don't include colour, so if you want to pre-render multi-colour vitamins, then each diff coloured component needs to be stored in a sep STL file...  this makes STL substitution for vitamins a right PITA.  Fairly straightforward for printed parts though.

[Jamie Osborne]

I was wondering if you could assign, say, a plated header pin hole object, to a variable and just use a copy of it - rather than generating a new one in each iteration of a loop, a having to use mirror etc. (if that even speed things up?).

Jamie

[Jamie Osborne]

@mal - don't forget to bring any changes to your model, so we can commit them later. (Not req. but would be a better demo)

Jamie

On 21 Oct 2014, at 12:06, Malcolm Pett <mal...@gmail.com> wrote:

--

[Damian Axford]

@Jamie - Nope, can't assign solids to variables.  However, OpenSCAD caches all levels of the CSG tree - so re-using the same part has the same effect.  

[Lilla Newton]

Hi,

I need someone who could give me some tutorial in pneumatics and hydraulics system.

I am struggling to understand the basic how the circulation works with a different valves and what valve do I use for what, how do I classify valves into logic system.

ASAP please as in few weeks I should design some basic systems for my first assignment.

Thanks

Lillie

[Damian Axford]

@Lillie - not my area of expertise I'm afraid....   also, could you start a new Topic for this, as it's unrelated to the LogoBot project

... and on the subject of LogoBot, and playing with auto-rendering of markdown, see the new prettier and more printable LogoBot manual:

https://rawgit.com/snhack/LogoBot/master/hardware/AssemblyGuide.htm

of course...  there's no content yet, but that's hardly the point :)

[jmeosbn .]

Looks nice... had thought of using Dropbox md source files rendered by the static hackspace site in a similar way.

Haven't used markdown-js or showdown - any dis/advantages between them?

Jamie Osborne

--