a link to any such code you may have found which suits my specifications. . . . . .

You're being silly.

Of course I can't refer you to any example code that shows how to link your specific remote control system to your specific type of motor. I doubt that anybody else in the world has implemented that specific solution.

However, when you break the solution down into its constituent parts they are all commonly done and there are plenty of examples around. I've already listed the functions that I would break it down into. No, I'm not going to link you to an example for each function, since some of them are trivially easy to find and the others are not hard to find. I'm not prepared to do the work for you if you aren't going to make even a token effort to work these things out for yourself.

This does the same thing (maps names to values) and doesn't use pointers (apart from the pointer to the constant string, which is the name of the item). No copying, no fiddling with taking addresses, etc.

It'd never occurred to me to use references other than for parameter passing, but now you've pointed it out that does seem pretty obvious. It's a neat approach, but using pointers instead of references would produce virtually identical code.

I'm trying to have a key switch, tabular solenoid and a (push) limit switch connected as an input to certain pins on an arduino.

I don't see how you would connect a solenoid as an input.

I have been told I need a solenoid driver or a relay.

If the solenoid is to be an output then yes: to drive a solenoid, you need some sort of driver circuit. It can be done quite simply and there are plenty of examples on this site. Or, you may be able to use a motor drive shield if you can find one that can support the voltage and current needed by the solenoid.

Try something like:

Code:

  for (int x = 0; x < 6; x++)
  {
    Serial.print(1<<x);
    Serial.print(", ");
  }

And here is the tidier one I am having problems with, using a for loop for the countdown.

Code:

void armsequence()  {
    lcd.begin(16,2);
    lcd.print("System Arming in");
    for (int count = 10; count > -1; count--) {
    lcd.setCursor(0,1);
    lcd.print(count(" Seconds...");
    delay(timer);
    mode = 2;
     }

That doesn't even compile, does it? You're missing at least one } and one ) to start with, and it's calling a function that doesn't seem to be defined.

If you're going to post code that demonstrates a problem, it needs to at least compile. As it is, I have no idea what that is supposed to do. What I'd expect to find was some code that sprintf()ed your message to a string buffer and then sent that to the display. What you actually have, I have no idea.

I would think, does he mean:

I think that's approaching certainty.

As long as you don't need to handle multiple keys being depressed simultaneously, I don't see why you can't just define a const for the return value corresponding to each key pressed in isolation and put those in a switch statement, pretty much as you were doing.

If you want to handle multiple keys then I would use a loop, bitshift and bitmask to test whether each bit was set and call a function to handle that keypress; in that function you could use a switch (key number) to determine which of the buttons was being dealt with.

Code:

Serial.println("Hello world");

I think that's a mistake. You're printing to the globally defined instance named Serial, instead of printing to this instance of HardwareSerial.

Since the global variable Serial has already been declared and defined, you can't change its type (i.e. from HardwareSerial to ScottSerial) unless you change the library that defines it.

The closest you can sensibly get is to define a subclass of HardwareSerial that acts as a proxy for a HardwareSerial and then define your own global instance of that subclass that wraps the Serial object. In order to have it act as a proxy you would need to provide implementations of all the public methods exposed by HardwareSerial that delegate the call to the underlying HardwareSerial.

Of course you do have the option of using a #define Serial MyExtendedSerial to make user code that appears to use Serial actually use your global proxy instead, although personally I wouldn't recommend it. I think that if people are going to code to an extended API it is reasonable for their code to reflect that, rather than try to pretend that the behaviour of the 'standard' API is no longer standard.

Even simpler, of course, is for each instance of the struct to contain a name and a value, rather than a pointer to the value.

I haven't followed the whole discussion, but I understood that the goal was to include dynamic values in text messages. In that case being able to include the current value of a variable (without imposing any complex mechanism to deal with updates to that variable) would best be done by storing a pointer to the variable rather than the value.

Yes, if there is no data on the SD card then that is the only way I know it failed. I have no clue how far it gets in the sketch.
The LED error code sounds like a good idea. Problem is I am a complete noob and I dont know how to do that or to check for other errors.

Do you have an LED on your Arduino? Or any unused output pins that you could use to connect an external LED? The 'blink' example is pretty much the first step in any Arduino learning curve and I find it hard to believe you're intending to debug an SD data logger if you don't know how to turn on an LED.

Code:

void armsequence()  {
    lcd.begin(16,2);
    lcd.print("System Arming in");
  for (int count = 10; count > -1; count--) {
    // turn the pin on:
    lcd.setCursor(0,1);
    lcd.print(count(" Seconds...");
    delay(timer);
    mode = 2;
     }

I can't believe that would compile, so it is pointless speculating about why it does the wrong thing. You need to post your actual code.

That's an argument against using relayState = !relayState, rather than against using that expression in the arguments to a function call.

There's nothing fundamentally wrong (IMO) in using expressions that modify variables in a function call.

[can]

This should be done by ramping or fixing the set-point not by making the PID loop slow.

I'd agree with "This can be done ...", but I don't agree with your assertion that this is the only correct approach.

The PID algorithm is capable of controlling the dynamic behaviour of a linear system i.e. controlling the acceleration and deceleration as well as the position. You can take control of that outside the PID if you want, but it's not wrong to use the PID to do it.

Can you help me understand this pointer issue a bit further ...
You seem to be saying that I should never increment/decrement pointers because I cant know what is where and cant therefore rely on the information I will get back.
This is because unless the variable is part of an array its location will chance even if its instance is never destroyed once its been created.

Is that correct, It seems counter intuitive ... Am I missing something?
Also why memory allocated to a global variable change in the first place?

Pointers hold the memory location of a piece of data. If you have a pointer to a char, then it holds the address of the memory location where a char is stored. You can alter the value of the char and that is fine - the storage location does not change, the pointer does not change.

When you increment a decrement a pointer, you are changing it to refer to a memory location which is adjacent to the original location. The compiler promises to keep elements of an array next to each other, so it is legitimate to use pointer arithmetic to refer to adjacent elements of the array - as long as you avoid going past the end of the array. But if the thing pointed to is not within an array, you the programmer have no way of knowing what is stored next to the original storage location. In that case, incrementing/decrementing the pointer is wrong - you would be changing it to point to an arbitrary piece of memory that you have no reason to assume holds anything in particular.

Having said all that, you do not need to use pointer arithmetic at all to do what you're doing. You will have an array of structs, and each struct will contain a name and a pointer to a variable. You can access each element of the array using foo [ i ] notation so there is no need for pointer arithmetic, and when you come to dereference the pointer you will just use the '*' operator.

Will all your variables be of the same type? If not, your structure ought to hold multiple pointers (one for each type you need to support) of which only one would be non-null for a given item.

how can I do this with out buying parts online?

Buy the parts offline? Are there any electronics retails shops in your area, or any retailers in your region that provide mail order or phone ordering?