Differences in Manuals

Has anybody kept track of the publication of the User Manuals? The newest is a 10/2013 version, and I wonder what the differences are between it and the 2012 version that I have. The PICAXE main web site suggests that you use this forum to find out if somebody knows it. (!)
Comments anyone?

There have been changes in product offered and some corrections - is there some reason you don't want to use the most current manuals? Perhaps being more specific if you are having particular questions would help.

It may be that the OP printed out the old manual and just wants to update the pages that have changed. I printed out the full manuals a couple of years ago and would like to do the same. Otherwise that's a whole lot of paper to reprint with every update.

I just compared man1 from 11/1/2013 and 9/21/2011 and there are a huge number of detail differences so it may not be easy to do the page update thing. Google will find a number of free, or non-free with a free trial, programs that will compare/diff .pdf's including the current version of Acrobat.

John West said:

It may be that the OP printed out the old manual and just wants to update the pages that have changed. I printed out the full manuals a couple of years ago and would like to do the same. Otherwise that's a whole lot of paper to reprint with every update.

Click to expand...

That is exactly the reason and the only one. Like John West, I printed out all manuals in 2012 when I started to use the PICAXE and use the second one all the time while I am learning how to program the chip. I would hate to find out if I had used a command that has been changed or improved without knowing about it.
BTW I am surprised by the answer of Revolution. I thought surely that they would know in detail what they revised in their updated printing.

Spelling corrected

hbl2013 said:

That is exactly the reason and the only one. Like John West, I printed out all manuals in 2012 when I started to use the PICAXE and use the second one all the time while I am learning how to program the chip. I would hate to find out if I had used a command that has been changed or improved without knowing about it.
BTW I am surprised by the answer of Revolution. I thought surely that they would know in detail what they revised in their updated printing.

Click to expand...

I'm agreeing with this as well. I don't like to waste things, and it pains me greatly to print unnecessarily. It would be nice if changes could be highlighted or something, going back one or two revisions.

tom

BTW I am surprised by the answer of Revolution. I thought surely that they would know in detail what they revised in their updated printing.

Click to expand...

I am not sure what the answer was, but RevEd is a relatively small company with only a few full-time employees. It is not likely that there is a full time tech writer, writing and updating manuals while documenting every change. They do a pretty good job given the available resources, but there is certainly room for improvement.

If I wanted a printed manual, I would compile it myself from the Online Manual as this seems to be the most current information.

I don't like it when people ignore my original question and make suggestions that do not address the question so I am a little reluctant to say this, but:

If you are using the manual to look at information while you program on your computer screen, may I suggest (very strongly) that you consider a two-screen computer setup? If you already have a computer with two video outputs (analog + digital) as most of us do, you can easily have a two screen system simply by purchasing a used second LCD monitor, and it can be practically any size. Then, you have the benefit of the manual open as you program, and the extreme convenience of computer search for the correct page of the manual that contains the information you need. And no more paper manual. I am using two 19" monitors which seem to work perfectly.

Goeytex said:

BTW I am surprised by the answer of Revolution. I thought surely that they would know in detail what they revised in their updated printing.

Click to expand...

I am not sure what the answer was, but RevEd is a relatively small company with only a few full-time employees. It is not likely that there is a full time tech writer, writing and updating manuals while documenting every change. They do a pretty good job given the available resources, but there is certainly room for improvement.

Click to expand...

That is pretty much it, and there are also practicalities as to what should be flagged as changed and against what baseline reference. When we release new software or a new chip range we generally produce datasheets which are specific to those which highlight additions, improvements and changes. As ever, it is difficult to do things in a manner which will satisfy everyone.

Won't some editors track and highlight revisions? It seems like I've seen that somewhere. Could the manuals be made available in a format that one of these editors could use? This wouldn't require any more effort from RevEd, but customers that wanted to know what was changed would only have to use the proper editor on their computer. Not having used such an editor, I hope I'm not over simplifying things.
tom

A revision note to say "Details of PICAXE 20X3 added" or "New command added" would be a good idea.

But as its highly unlikely you could actually do a page swap of a old printed manual to bring it up to date, why would you want to know the exact detail of each and every change or typographical error ?

I just use the latest manual, seems to work for me.

geezer88 said:

Won't some editors track and highlight revisions? ... Could the manuals be made available in a format that one of these editors could use? ... Not having used such an editor, I hope I'm not over simplifying things.

Click to expand...

I haven't used such things either but can see how it's probably not as simple as it might appear, not least that current documentation has to be moved to that format and one has to find such an editor in the first place, which really needs to be available for free for users of a variety of operating system. Unless it can replace what is currently used it simply adds something else which has to be updated and maintained.

There's always going to be some cost and effort involved and that has to be weighed against the benefit gained and a business case made for doing it. The costs and efforts of producing documentation and maintaining that are usually a lot higher than may be imagined. Knowing what's changed between manuals is probably of little interest to most users but adding some 'history' might be worthwhile.

I'm old enough to remember writing slates, I have two B&W laser printers, and a color laser, but they don't see much use because I've pretty much weaned myself off printing anything. I use the .pdf's and enjoy the search facility, I can't imagine going back to paper. Try it, you may like it

Oh my I used to get data in 3 ring binders which the manufacturers would send out new pages for revisions and new products - now I do ok with PDFs that are searchable and get annoyed with the ones that aren't. One thing I'd like in the PICAXE manuals is some clusters of related commands which aren't alphabetically related - e.g. setting up ref voltages FVR & READADC. Some times I hunt through the whole list just to find the command I know is there but can't remember what it may be called. A "See related commands" list under the main one.

Document histories and updates can be very painful but very useful. I seem to spend 90% of my time doing that these days.

You don't list individual typographical errors unless they involve functional descriptions or errors in specification or numerical data; even then you might just list the section involved.

The downside is time ... I do 'em so I have a vague idea.

The upside , and value, varies with the audience.
For those who don't read the manuals and leap straight to the Forum a 'history' would have little value.

But for those a little more experienced or serious then the value would be higher.
For example: my code from last year is playing up when I load it today.
Aha! The history says "Change to parameter list for Command 'WobbleDobble'; Release 12.01 (July/2014)"
I'll go and look.

Or; Change to reserved Words (Release xx Date yy) - I've seen plenty of confusions with lables and reserved words happen here.

It may just list a Section or Command which has changed.
Then the reader potters off to that section and checks for details.
Brevity is fine as long as you are pointed in the right direction.

Doing brief Revision Histories are easy while you are actually doing the revision but a pain retrospectively.
Check how Microchip do it. It doesn't need to be hugely complex.

I've been known to sit on the bus and read my hardcopy PICAXE manuals. They have the important benefit of requiring no battery power whatsoever, no matter how long I leave them lying around unplugged, and if they slide off my lap I don't panic as I would with an expensive laptop PC. However I understand Rev Eds difficulty with staying on top of every detail the way a Fortune 500 company would, so I don't expect them to. In fact, I'm impressed with how much they do accomplish with the limited manpower they have.

As for the suggestion that we use two display monitors at the same time, some folks must have far larger workbenches than I do, because I've also been known to set my soldering station on the floor in order to get sufficient room to move my mouse. But then, I'm a pack-rat with too much equipment and far too many electronics parts.

My suggestion to the OP is to find someone in a large corporation with a big fast printer and ask them to run off a new copy for you. That's what I did.

For me the issue is not spotting a new command or feature that has appeared so I don't use it when I could. I gave up printing when I realised that a) downloading a pdf of nearly 300 pages only took a few seconds (on my broadband at any rate) and so clearly wasn't going to be a problem, and b) I discovered how printer manufacturers make their money.

A cumulative forum entry highlighting the new stuff and where to look for the details might be a welcome addition. But don't expect people to trawl through lots of pdfs or web pages just in case there is a nugget to be found.

By the way, two monitors is really useful and most graphics cards will take two as a matter of course (often one VGA and one DVI or HDMI) without extra hardware, making an enlarged desktop across both (at least with Ubuntu). You could always stack them. Or hang them. I wouldn't be without.

hippy said:

There's always going to be some cost and effort involved and that has to be weighed against the benefit gained and a business case made for doing it. The costs and efforts of producing documentation and maintaining that are usually a lot higher than may be imagined. Knowing what's changed between manuals is probably of little interest to most users but adding some 'history' might be worthwhile.

Click to expand...

In my opinion, change logs are required no matter the topic. Revision history are already added for changes to PICAXE ICs and the PICAXE Editor, so when changes are made to the documentation, they should be easily added as well. It's not like thousands of changes are made at one time, so adding 2 or 3 here and there should be in the noise level of time required. Ultimately, I think a "Revision History" tab on the BASIC Commands page like what is on the 14M2 product page would be excellent. Even a simple hyperlink to a new section of the support forum that is only writable by RevEd employees for doc changes would be sufficient.