- The axis lines for the ground trail dimension remain visible when the dimensions are made invisible.
- The width of the dimension extension lines isn't independently adjustable from the width of the outline. While a 0mm outline works very well since it's the same size at every scale, a 0mm dimension extension is very difficult to see.
- The rear dropout diagram has the seatstay dimensions Sx and Sy above the chainstay dimensions Cx and Cy but below the chainstay dimensions in the input fields.
- Updating the notes/caption with the Edit feature doesn't carry over to the save dialog when the design is opened with BikeCAD.
- Several dialogs are updated piecewise (e.g. brakes and fenders) rather than as a unit (e.g. wheels).
- There are a lot of redundant colors in the color pallet. They greys in particular.
- The adjust paint widget feature doesn't shut off when the paint dialog is closed.
- The refit function turns off the adjust paint widget (e.g. for spear) whether the paint dialog is open or not. Zooming in/out sometimes turns off the adjust paint thing as well.
- At least under Xfce in Xubuntu, the gearing graph is never initially displayed large enough to show more than the display dropdown menu and doesn't resize to fit the full gearing graph as chainring/sprocket count changes.
- The "Open model in BikeCAD" link seems like it should be more prominent. For some reason I occasionally click "Edit" expecting that to open the model in BikeCAD.
Tue, Aug 27, 2013
#1
A few niggles I've noticed.
Thank you very much for the excellent feedback! I've managed to address a number of these points. My corrections won't appear until I release the next update which should be in the next month.
When I said "several dialogs are updated piecewise" I was referring to, for example, not being able to enter numbers for both the front and back brakes (and, incidentally, the cantilever bosses) and then updating everything in the dialog box at once the way it's possible to with the wheels. Each brake and each boss has to be updated independenty, but I can update both wheels with one press of the Enter key whether the "set front equal to rear" box is checked or not. It's just a minor inconsistency I noticed. It would however be nice to be able to what you said and set the front and back brakes identically, the way you can with the wheels.
While you may feel the extension lines are perfectly visible in the image you posted, my eyes still have trouble seeing them. Not as much, though, as I have with the image below, which is an example of what a black 0mm dimension/extension line looks like with the default background color. It's almost completely invisible to me, but it's still better than white, red, or yellow even though they should have more contrast with that background color.
As an addendum, I also noticed that the front rack is drawn in front of the handlebar when there's any overlap.
Thanks for the clarification.
As for the front rack display, I've also noticed that and have corrected it for the next update.
As per your suggestion, I've made dimension line weight independent of outline thickness in BikeCAD version 10. The change is explained at: bikecad.ca/dimension_line_weight.
Cool!
It looks like the W and T fields are missing from the fork dialogue for the two non-suspension styles.
Only thing I've found so far.
Thanks for the feedback. I've just posted a corrrected version. I've also addressed the issue with the Gearing Graph dialog box that you mentioned earlier.
I like the way it highlights the gear the chain is on. Also, when I went to change the gear that was hilighted, I found a couple RPM's next to the Extra links and Pulley teeth fields in the Drivetrain dialogue that seem out of place.
Thanks for bringing that to my attention. You are incredibly observant. Your feedback is much appreciated.
It's cool that the color applet now updates the model on the fly, but pushing "Cancel" doesn't revert to the original color even though the original color is retained and displayed for comparison.
The fender struts display behind the belt/chain.
And the most serious so far. If there's more than one gear in back and the gear the chain is supposed to be on doesn't exist (e.g. the derailer's on "5" but there are only three gears), the program hangs without errors when trying to display the chain. I've let it sit for 20 minutes before giving up on it. This is repeatable 100% of the time for me.
Thanks for this. I will try to address these issues in the next update.
I've once again updated the free version of BikeCAD.
BikeCAD version 10.03 will retain your original paint color if you choose Cancel in the color chooser.
Version 10.03 also corrects the issue with the fender struts appearing behind the chain.
I could not replicate the issue you observed with the gears and chain. The numbering of the gears is explained at: bikecad.ca/chain_or_belt_drive If a cassette only has 8 cogs, then choosing to run the chain on cog 11 would actually place the chain on cog 8. Similarly, if a crankset only has two chainrings, then placing the chain on chainring 3 would be the same as placing it on chainring 2.
Version 10.03 also includes a few more brand logos.
Version 10.01 was complled on Java 1.7. This proved to be a problem for users running earlier versions of Java. BikeCAD version 10.03 was compiled on Java 1.5 and will therefore run on Java 1.5, Java 1.6, Java 1.7 etc.
It may be necessary to clear your Java cache in order to access the latest version of BikeCAD.
The rear disc brake posts don't seem to change color with the chainstays on multi-color paint jobs while the paint is adjusted.
The wheel cut diameter on an aero downtube is adjusted with the wheelcut diameter on the aero seat tube. Contrast:
and:
The spider arm phase shift behaves a bit inconsistently. Even-numbered crank spider values have a spider arm in line with the crank arm when the slider is all the way to the left but odd-numbered values have a spider arm inline with the crank with the slider all the way to the right. I'm sure this is a design choice on your part, but I don't really understand why you'd want it done this way.
Also, both the front rack and the front cargo now display over the handlebars. Maybe we have different ideas about how things should work, but when I mentioned the issue previously I was expecting that the rack and cargo would be drawn under the handlebars.
I haven't been able to repeat the chain/gears thing recently, either.
Thank you very much for your continued feedback. It's a tremendous help.
I've corrected the issue with the paint colour on the disk brake tabs and posts. I've also fixed the wheel cut diameter issue on the down tube.
The image below illustrates how the crank spider changes as you go from 3 arms up to 6 arms. As you can see, it's the arm opposite the crank that remains stationary as long as the phase shift slider is set all the way to the left.
I actually did correct the rack and cargo display order in BikeCAD 10.01. Unfortunately, when I made further changes in 10.03, I accidentally reverted what I had fixed. I have fixed it once again.
None of these corrections will actually be available until I update BikeCAD again. I hope to have that out soon.
Bugs:
* The "include fork in paint scheme" option in the "Paint" window doesn't pass the color option to the fork's disc brake mount.
* In the main window, the "change color" option in the right click menu for the handlebar changes the bar color only when the bar type is "Mountain bar", otherwise it changes the background color.
* In the "Seatpost" window, when the middle seatpost clamp type is selected and the "B" and "C" dimensions are identical, the clamp shows as a solid circle. Varying "B" or "C" by 0.1mm makes the saddle rail visible again.
* The "tapered" head tube option in the "Tubing" window is missing the "A" field.
Feature requests:
* The organization of the text entry fields for many windows could probably stand general revision. Some, like the "Primary dimensions" window, are excellent because they are descriptively labeled and well-organized. Some are just slightly odd, like the variable seat tube diameter tube options where the "J" and "K" labels are at the top of the diagram but the "G" and "H" fields are at the top. And some, like the saddle dimensions, are a bit of a treasure hunt, even with the reasonable compromise of organizing the fields alphabetically. It's probably too much to expect that complicated diagrams are labeled with perfect clarity, but a better match of the map to the territory and more descriptive labels whenevery possible would probably improve general usability.
As always, thanks for the excellent feedback.
I will definitely correct the issue with the color on the disc mount.
For the right click "change color" of the handlebar issue, I was not able to reproduce this error. Is it possible you took note of this in version 11.0? I did make a correction to the handlebar color selection in version 11.5. I had thought everything was working correctly now.
The behaviour of the seatpost clamp when B and C are equal was something I did intentionally. The idea was to better represent Kent Eriksen's Sweetpost. This style of seatpost has a solid cap on either side of the clamp. However, just looking at the image below, I see another issue I hadn't considered before. The rails don't actually pass through the center of the circular clamp, they seem to pass through it about a quarter of the way down from the top. I wonder if I should add another dimension to allow for the rails to be offset from the center of the clamp.
In tapered head tubes, there is not meant to be an input field for dimension A. I only included the label in the diagram because it is still available to be shown as a driven dimension. I had wondered at the time if this might cause confusion. Perhaps I could show the label in grey instead of black?
I thought the seatpost thing might be intentional since it was such unusual behavior, but being able to display that particular seatpost makes the program misrepresent other seatposts like the Enve and Moots pictured below. Maybe make it switchable with one of those two position pictures you use for tube miters? That way people will know it's an option without having to stumble on it by accident.
For the bar color thing, I'm definitely using version 11.5 according to the "About" menu (I can't open both the "Choose color" window and the "About" window at the same time to show both in the same picture for some reason. Or, really, do anything but close the "About" window when it's open. Bug or feature?), and I've found the bar color bug 100% repeatable with road and bullhorn bar types. Things do work as they ought to with MTB bars.
The right click color change on road and bullhorn bars opens the background color widget, as below. Maybe zoom in and set the bar to a contrasting color with the grip/tape and stem (in the image below, the bar is red and the stem and tape are black), or make the stem's "M" value very large. It can be tricky to click such a thin section.
For the tapered head tubes, it's not so much that implicitly defining only "A" is confusing, it actually causes a few usability problems. For example, the dimensioned drawings for the Paragon Machine Works' tapered head tubes you include as standard head tube types definitely have an equivalent to the "A" dimension but no explicit "B" dimension:
I expect it's done this way because the "A" and "E" dimensions are consistent over all the available lengths in that product line. Setting "A" implicitly for these head tubes means that to change the head tube length you need to change things in the "Tubes" window as well as in the "Primary dimensions" window. For non-standard head tubes of this specification type, you also have to do math to change the length of the head tube. All of which is easy to forget because you can change the head tube length in the "Primary dimensions" window without correcting things in the "Tubes" window. For this type of head tube, it's probably best to implicitly define "B". On the other hand, the Nova Cycles Supply and Columbus tapered head tubes have large "E" dimensions suitable for cutting to length, again making two changes and arithmetic necessary when varying the head tube length, which suggests they'd benefit from being able to implicitly define "E" instead. I can't find any tapered head tubes designed to be cut to length from the bottom, which is the sort of tube that would benefit from an implicitly defined "A" value.
How about this as a solution: explicitly define "A" and have a drop down menu to choose whether to define "B" or "E" explicitly?
Thank you for clarifying the issue with the handlebar colour. I tend to focus all my attention on the bar tape section of drop handlebars and forgot about the actual handlebar section.
I did start out with the intention of making the A dimension in tapered head tubes the one that would be directly controlled. This would have been possible in many scenarios. However, when defining the front end geometry by effective top tube length, and the head tube extension by the length of head tube measured along the edge, I have a situation where I need to know the diameter of the head tube at a specific point along the head tube before I know the actual head tube length. In this circumstance, it was a whole lot easier to make B the dimension that is directly controlled. I hope people will be okay with this constraint for the time being.
You could actually remove the tapered head tube option entirely. Setting the variable head tube to d=Ø gives the same functionality (and is probably how you do it in the code). Ditto d=D, but it truncates the tube from the top instead, making it a slightly less annoying option, at least from my perspective of not being able to find tapered head tubes that are sized by cutting stuff off the bottom. Of course, by this standard you could also remove the constant diameter head tube feature as well, which would make having a constant diameter headtube unnecessarily complicated.
In any case, I noticed with many of the entry fields that if I do calculations in them, I get small but unexpected errors. For example, if I wanted offset a 31.8mm down tube at a 38.1mm bottom bracket so that the lower edge of the down tube was reasonably approximately tangent and inputted "(31.8-38.1)/2", it returns "-3.1500000000000004" instead of the correct "-3.15". I can understand this sort of thing happening occasionally when switching from one type of input to another and back because of the need to calculate conversions both ways, but it probably shouldn't be happening to numbers only entered a field.
Also, as a feature request, I would love if we could reference other variables when doing calculations in the fields. Being able to set, say, the wheel diameter by inputting "BSD+2*W" would be kind of neat.
I agree with your point about tapered head tubes. I acknowledged the option to model a tapered head tube using the variable diameter option in the video at: bikecad.ca/headtube_profiles.
I have just revised the expression solver to present calculated values more cleanly.
I will investigate ways to allow users to reference other variables in a given input field. In the meantime, if there are individual calculations that you find you are doing repeatedly, maybe certain input fields could have extra menus associated with them so that those calculations could be done automatically. I don't think I will do that with the bead seat diameter and tire width example because while BSD+2*W=tire diameter is often a reasonable approximation, as discussed here, it is too often assumed to be true when it isn't.
Hey Brent,
I'm loving all the new features and the program in general. However, recently I've run into a goofy bug (unless I'm screwing things up which is a possibility): when I compare saddle setback using an Aliante saddle the BikeCAD (v.11) gives me a number that is about 20mm more than it is in reality - ditto for the reach to the bars. The saddle measurements all seem to be accurate and when i compare with older versions of my drawings they don't seem to have this bug. Am I making sense and any thoughts here? Apologies if this has been covered or fixed in an update.
Cheers,
Steve Hampsten
I'm confident that none of the dimensions for the Aliante saddle have changed since they were introduced in version 9.15. If there are discrepancies between older designs and newer designs, I'd suggest investigating the possibility that older designs might have used different values of seatpost setback or different fore and aft position of the saddle rails in the saddle clamp.
Meanwhile, I would hope that the observed discrepancy between the model and real world measurement could also be explained by seatpost setback or saddle rail position. However, it is also quite possible that the Aliante model is in need of some tweaking. Currently, all of the standard saddles in the library were contributed by other BikeCAD users. I did not have access to this full range of saddles to confirm these measurements. Perhaps you could take a few measurements of your own fi'zi:k Aliante and let me know if the current model could be improved.
I have measured my Aliante and your numbers seem to be right on the money. I'll keep digging - I imagine the problem is staring me in the face...
After much measuring and remeasuring I'm going to say that my prior confusion was simply a series of errors piled on top of other small errors. In other words, BikeCAD is right, I was wrong.
Thanks for the info. It's always good to know when there has been confusion. I hope to reduce those incidents over time.
Well, one problem and one feature request.
The problem you fixed with the disc brake mount on the fork not taking the color of the fork when the "include fork in paint scheme" option is selected also occurs with the cantilever posts.
The feature request is to have the bar end shifters point backward on mountain bars, like on road bars, instead of forward, like on bullhorn bars. Or to make them manually reversible. This would be useful when trying to make swept back French/porteur-style handlebars. As it is now, the mountain bar must be rotated 180 degrees to get the shifters to point backward, which also puts the shifters upside down and reverses the bar's measurements, making the bars harder to work with. I've tried making porteur bars from drop bars, but the bars break when negative drop and reach values are used. And using bullhorn bars to make them is even more of a pain in the ass.
Thanks for the feedback and suggestion. I have addressed both those points in BikeCAD version 12.