Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[BrianTRice@gmail.com]

Received the ChargeTank Hardware And Inlet Bracket Kit p/n #12-08047XX (old p/n 12-0804713). Taking pictures will do a write-up if I can figure out how it is supposed to mount.

For various parts received do we want to keep this information inline or should we refer to a single listing of Zero OEM parts and p/n's?   It seems that a table of known part numbers with associated installation write-ups might be handy.

A table is a good way to get people to fill in more data and understand the part numbering system or something. It's more work, but you went through all that trouble on the torques table, and this should be easier (since it's partial) than that? I may regret claiming that, though...

[Shadow]

A table is a good way to get people to fill in more data and understand the part numbering system or something. It's more work, but you went through all that trouble on the torques table, and this should be easier (since it's partial) than that? I may regret claiming that, though...

The torques (fastener specifications) table is flawed;  the source of information should be in a database, and the view be a windowed query embedded as a table. When making a write-up on belt adjustment say, I'd like there to be an embedded table view that shows only the relevant datum for axle bolt, belt tensions, sorted on the model(s) and year(s) we are interested in.

I could not figure out how this would work from within Media Wiki. I'll get back to the fastener specifications when there's a way to make it more useful in write-ups. There's plenty of fastener specifications that are either not in the owners manuals and/or are standard engineering values.  On that note, I don't have an engineering degree. Is there some well known reference to figure out what torque value is?  A brief search engine attempt shows several fastener manufacturers guides and recommendations, but is there a recommended source of information that should be preferred to cite when no official recommendation is available?

[BrianTRice@gmail.com]

A table is a good way to get people to fill in more data and understand the part numbering system or something. It's more work, but you went through all that trouble on the torques table, and this should be easier (since it's partial) than that? I may regret claiming that, though...

The torques (fastener specifications) table is flawed;  the source of information should be in a database, and the view be a windowed query embedded as a table. When making a write-up on belt adjustment say, I'd like there to be an embedded table view that shows only the relevant datum for axle bolt, belt tensions, sorted on the model(s) and year(s) we are interested in.

Yes, a wiki is just a document and the table system falls over beyond sorting.

At some point, I'm strongly considering shifting to Github where I can colócate documents with a database-backed application without losing my patience with system administrative overhead. (Postgres with caching and some React thrown in front, say, with cloud style hosting)

In the meantime, I'll go check to see whether the wikidata project has an answer for this specific case built into mediawiki.

I could not figure out how this would work from within Media Wiki. I'll get back to the fastener specifications when there's a way to make it more useful in write-ups. There's plenty of fastener specifications that are either not in the owners manuals and/or are standard engineering values.  On that note, I don't have an engineering degree. Is there some well known reference to figure out what torque value is?  A brief search engine attempt shows several fastener manufacturers guides and recommendations, but is there a recommended source of information that should be preferred to cite when no official recommendation is available?

Okay, so your concern is already limiting what we put in there so that makes it not theoretical.

If we infer data points, we'd want to make that reasonably obvious.

I don't know sources like this myself. Maybe someone else knows.

[BrianTRice@gmail.com]

Just a note that I'm really busy in the last couple of weeks, so I haven't done much with the wiki and am way behind reading forum threads.

[Shadow]

Now playing with LibreOffice Base 5.3 for a forms database, also purchased a calipers and a few fastener thread guides. Goal is to design a database that can soak up all of the "meat space" specifications we can know about for export to the wiki, or maybe as some kind of complementary thing that can be referenced from the wiki.

Notably I remember being asked to confirm what kind of fasteners were part of the Non-Police DS Drop Bar kit. I had not the means then to be sure, but that along with other things I can physically measure will become part of the database.

LibreOffice Base 5.3 and newer use Firebase 3.0 which has some useful database features over the earlier use of Firebase 2.5

[grmarks]

sounds to me like this database is a great fit for Ruby on Rails hosted on Heroku using Postgresql. All free
using github for the repo.

[Shadow]

sounds to me like this database is a great fit for Ruby on Rails hosted on Heroku using Postgresql. All free
using github for the repo.

Want to set up that web backend? I can do data entry and form the database structure and some of the queries I'd want to see. Having a technical database as a companion to the unofficial manual wiki makes a kind of sense.

Open for comment, does this idea fit well with the wiki?

[grmarks]

sounds to me like this database is a great fit for Ruby on Rails hosted on Heroku using Postgresql. All free
using github for the repo.

Want to set up that web backend? I can do data entry and form the database structure and some of the queries I'd want to see. Having a technical database as a companion to the unofficial manual wiki makes a kind of sense.

Open for comment, does this idea fit well with the wiki?

I see it as a just being a link (as it is now from the index) to the web site on heroku.
I think we would need guest and admin profiles so the average user does not accidentally change any data. What do you think?
I can do it and post a link here for you to look at and give feed back.

[Shadow]

I see it as a just being a link (as it is now from the index) to the web site on heroku.
I think we would need guest and admin profiles so the average user does not accidentally change any data. What do you think?
I can do it and post a link here for you to look at and give feed back.

I'm open to either approach, for a web database app and edit data online, or a view-only web app that any changes made are commits to the git repo.

For example of usage I would like to include in the wiki a reference to fastener torque value for a 2012 MX swingarm main pivot bolt. The URL http://x.yz/ZeroMotorcycles/2012/MX/SwingarmMainPivotBolt would emit a table view of the related data. MediaWiki would be configured to accept an IFrame embed from that URL path so that this appears seamless when being viewed by any user.

[grmarks]

I see it as a just being a link (as it is now from the index) to the web site on heroku.
I think we would need guest and admin profiles so the average user does not accidentally change any data. What do you think?
I can do it and post a link here for you to look at and give feed back.

I'm open to either approach, for a web database app and edit data online, or a view-only web app that any changes made are commits to the git repo.

For example of usage I would like to include in the wiki a reference to fastener torque value for a 2012 MX swingarm main pivot bolt. The URL http://x.yz/ZeroMotorcycles/2012/MX/SwingarmMainPivotBolt would emit a table view of the related data. MediaWiki would be configured to accept an IFrame embed from that URL path so that this appears seamless when being viewed by any user.

Just a rough cut (not sure about the Citation bit, I just made it text) Play around with it let me know if you want more fields. Styling will come latter.
table on server

[MrDude_1]

Just one mention about this plan..
the idea of the Wiki is to contain the information on in the wiki. NOT to link to external sources. While they can of course be referenced, the information needs to still be in the wiki site itself.

Otherwise you're dependent on another website to be up and useful.  The entire point is so that if this board were to crash and go away, or someones random personal page with good info was to disappear, you would still have all the info you need in one place. The wiki itself is professionally hosted, backed up and maintained in a data center with mirrors in 3 physically different parts of the country.. so it should never be "lost".  But anything it links to can be.

Im still lost on how some static data belongs in a different database. I dont know if you're aware, but everything in the wiki, is in a database, complete with versioning history and everything. nothing is lost.

[grmarks]

Just one mention about this plan..
the idea of the Wiki is to contain the information on in the wiki. NOT to link to external sources. While they can of course be referenced, the information needs to still be in the wiki site itself.

Otherwise you're dependent on another website to be up and useful.  The entire point is so that if this board were to crash and go away, or someones random personal page with good info was to disappear, you would still have all the info you need in one place. The wiki itself is professionally hosted, backed up and maintained in a data center with mirrors in 3 physically different parts of the country.. so it should never be "lost".  But anything it links to can be.

Im still lost on how some static data belongs in a different database. I dont know if you're aware, but everything in the wiki, is in a database, complete with versioning history and everything. nothing is lost.

I would suggest heroku is a far more stable host than this site, as often I find it down. Heroku is a professional hosting server that many companies use. Admittedly this is on a hobby dev within the server (which is free hosting up to 10,000 rows in the DB)
You can read about it here.

Ultimately BrianTRice should have the last say as to what he wants or what is a good idea as its his baby. I will just go with the flow.
A real DB lets you run queries to subset the data so thats the advantage as Shadow pointed out.

[Shadow]

Just one mention about this plan..
the idea of the Wiki is to contain the information on in the wiki. NOT to link to external sources. While they can of course be referenced, the information needs to still be in the wiki site itself.

Otherwise you're dependent on another website to be up and useful.  The entire point is so that if this board were to crash and go away, or someones random personal page with good info was to disappear, you would still have all the info you need in one place. The wiki itself is professionally hosted, backed up and maintained in a data center with mirrors in 3 physically different parts of the country.. so it should never be "lost".  But anything it links to can be.

Im still lost on how some static data belongs in a different database. I dont know if you're aware, but everything in the wiki, is in a database, complete with versioning history and everything. nothing is lost.

I would suggest heroku is a far more stable host than this site, as often I find it down. Heroku is a professional hosting server that many companies use. Admittedly this is on a hobby dev within the server (which is free hosting up to 10,000 rows in the DB)
You can read about it here.

Ultimately BrianTRice should have the last say as to what he wants or what is a good idea as its his baby. I will just go with the flow.
A real DB lets you run queries to subset the data so thats the advantage as Shadow pointed out.

Thanks for setting this up! I fully agree that the data should live in the wiki database, but there is no way obvious to me how to do this. I'm of course willing to make measurements on my Zero and do data entry! There just needs to be some good mechanism for the data to be useful after it is entered.

My own ambition, beyond maybe what Brian would like, is that "Zero Manual" not be limited Zero Motorcycles vehicles.

At danger of over-thinking this... more general purpose for the field names would allow us to form a parts database. Mostly I am thinking of fasteners and torque values, where i.e. Bolt Depot's Identifying Fasteners guide says five fields is enough. All of the world's life in science studies are described by seven categories, and the well known "O.S.I." model has seven layers as well. I think we need at least five to describe fasteners, and seven is pretty close to that so we can assume seven categories.

The basic tables layout having [foreign key] and {unique key}:

MakeYearModels (Make, Year, Model)
Cats ({Name}, A, B, C, D, E, F, G) ; "Fastener"=>Type,Material,Diameter,Length,Thread,NULL,NULL
Items ([CatName], A, B, C, D, E, F, G) ; [Fastener], Shoulder Bolt, Alloy Steel, 10mm, 100mm, M8

and beyond this we can go into applications Apts of those items

Apts ([MakeYearModel], [Item], Name, Minimum, Nominal, Maximum, Unit)
OEMParts ([MakeYearModel], [Item], Partnumber, Description)
Citations ([Application], Description, URL)

This works if you have multiple Items (bolt, with a nut, each is a fastener) for an Apt. That part of the idea needs a little refinement perhaps.

The overall desire I have is for a parts database, with torque/pressure/partnumbers, and perhaps references back into the wiki, that we can query by URL and inset to the wiki.

[MrDude_1]

I would suggest heroku is a far more stable host than this site, as often I find it down.

When you say "this site" do you mean electricmotorcycleforum or zeromanual.com?

Heroku is a professional hosting server that many companies use. Admittedly this is on a hobby dev within the server (which is free hosting up to 10,000 rows in the DB)
You can read about it here.

Ultimately BrianTRice should have the last say as to what he wants or what is a good idea as its his baby. I will just go with the flow.
A real DB lets you run queries to subset the data so thats the advantage as Shadow pointed out.

Zero manual is hosted on Pair Networks.. and does support mySQL databases... if you want me to setup a real database on there in mySQL I can. just the code and everything will need to be on that server, for the same reason.. as long as the site exists, the information is all there. no external info needed. It would be a real development project though.

[MrDude_1]

Thanks for setting this up! I fully agree that the data should live in the wiki database, but there is no way obvious to me how to do this. I'm of course willing to make measurements on my Zero and do data entry! There just needs to be some good mechanism for the data to be useful after it is entered.

I am all for making data entry easier and searchable... if theres some tool or program we can add to do this easily I can go forit.. but if its a custom development situation I would have to delegate someone else to do it for me. As much as I love helping I dont have the time to follow through. I recently changed jobs to something with a faster pace, and Im not online throughout the day with downtime anymore.

My own ambition, beyond maybe what Brian would like, is that "Zero Manual" not be limited Zero Motorcycles vehicles.

the Zero Manual site is for zero bikes.. thats a large enough segment to cover.  If we end up with a great site/product I dont mind making another site, either specific to something else or generic, but remember... someone has to put the information in. We are lucky to have someone like BrianTRice to input massive amounts of data and format things clearly. Most bikes wont have someone like him that is both dedicated and knowledgeable on the subject.

At danger of over-thinking this... more general purpose for the field names would allow us to form a parts database. Mostly I am thinking of fasteners and torque values, where i.e. Bolt Depot's Identifying Fasteners guide says five fields is enough. All of the world's life in science studies are described by seven categories, and the well known "O.S.I." model has seven layers as well. I think we need at least five to describe fasteners, and seven is pretty close to that so we can assume seven categories.

The basic tables layout having [foreign key] and {unique key}:

MakeYearModels (Make, Year, Model)
Cats ({Name}, A, B, C, D, E, F, G) ; "Fastener"=>Type,Material,Diameter,Length,Thread,NULL,NULL
Items ([CatName], A, B, C, D, E, F, G) ; [Fastener], Shoulder Bolt, Alloy Steel, 10mm, 100mm, M8

and beyond this we can go into applications Apts of those items

Apts ([MakeYearModel], [Item], Name, Minimum, Nominal, Maximum, Unit)
OEMParts ([MakeYearModel], [Item], Partnumber, Description)
Citations ([Application], Description, URL)

This works if you have multiple Items (bolt, with a nut, each is a fastener) for an Apt. That part of the idea needs a little refinement perhaps.

The overall desire I have is for a parts database, with torque/pressure/partnumbers, and perhaps references back into the wiki, that we can query by URL and inset to the wiki.

theres already a semi-standard way this is done for OEMs, salvage yards, insurance quotes, and parts suppliers.  However I dont have access to their software or specs. if someone wants to look into this further, and it can be run on our servers, i might support it. A good plan would need to be constructed, and as I said, im time limited. right now,im litterally typing this in a meeting as that seems to by my only downtime right now. lol