Has anyone successfully (or unsuccessfully) run the PID library on the DUE?

What's the distance here? ...People talk about maybe 5-10 feet, and it sounds like your distances are much greater.

No, far less.  The whole contraption is only 5 feet long.  The application is a three vessel brewery, like these:
https://www.google.com/search?q=brutus+10&um=1&ie=UTF-8&hl=en&tbm=isch&source=og&sa=N&tab=wi&ei=O_u3UaOcK4TU9gTA1IGAAw&biw=2560&bih=1509&sei=vfu3Uf-3PIXy9gSas4G4Cg

These are commonly built with a large control panel built on a huge NEMA enclosure.  There is usually a 220 feed, controlled by PIDs and relays, and then numerous 220 lines go to various parts of the brewery.  See http://www.theelectricbrewery.com/gallery to get an idea of what I mean.
Here's the scene I want to avoid: http://www.beerobsession.com/wp-content/uploads/2011/04/IMG_0695_rdy.jpg

My intent is to minimize the 220 wiring by having a din rail run basically the length of the brewery, and having the SSR's as close to the elements, valves and pumps as possible.  I'd have an I2C slave board for each component, so I'd really only need four wires for all of the controls.  These phase angle controllers are going to be three of those slaves.

So, I guess have options:

1.  draw an I2C slave for the pumps with the microcontroller, the 220 relays, all of it, and mount it right on the pump bracket.
2.  draw a board for just the 220 parts - the mechanical relay, the SSRS, and the H11A1, and send the zero-crossing signal back to an I2C slave on the DIN rail (~9 inches away from the AC pump motors).
3.  draw a board for just the 220 parts - the mechanical relay, the SSRS, and the H11A1, and send the zero-crossing signal back to the control panel itself (2-5 feet from the pump motors).

Found this elsewhere:

"The thickness of copper clad on a circuit board is usually given in ounces (oz). It is the weight of copper on one square foot of board. One ounce copper is 1.378mils (~35um) thick."

Thanks for looking that up!

IOW, when using 220 VAC and inductive loads, there are many factors that need to be taken
into account, and industrial controllers for these sort of apps tend to have all sorts of EMI,
ESD, and other suppression and noise filtering circuitry. Basically, this is a nasty environment,
and little 5V controllers can have reliability problems. I'd suggest you do some background
research on this whole topic.

Thanks for the response, and the advice!

So, a wiser choice may be to put the H11AA1, the SSRs, and the mechanical relay in a little enclosure next to each pump, and send the zero cross pulse back to a control board that's distant from the 220 portion altogether?

so although trace width is a flexible choice you want to try to be conservative - but you can increase that 1C to 2 or 3 I think.

Thanks a lot for your reply!  I thought that 1 was the most conservative option.  A 2 degree tolerance calls for 81.71 mils; 3 degrees calls for 63.88.

Are you saying that I would benefit from the narrower trace and should use it because of expansion issues? Or just that I probably could get away with it if I wanted to, because a 2-3 degree temp rise is trivial?

I want to use the example found at http://playground.arduino.cc/Code/ACPhaseControl to control the speed of some pumps.  The pumps, located at http://chuggerpumps.com/product.php?prodid=237, are 220v, 290 watt, thus pulling around 1.3 amps correct?

The board house I've been using is iTead.   Outside conductive layers are 35um. I'm using this trace width calculator: http://www.desmith.net/NMdS/Electronics/TraceWidth.html

I put in the following number:
Amps: 2
Rise: 1 degree
Thickness: 35um
Ambient: 40 (it gets hot out in the garage/driveway!)
Trace length:  20mm (I put the SSRs and H11AA1 right at the edge of the board, actually less than 20mm)

The output is that I need 125mil of trace width, with >71mil of space. 

I have no reason to doubt the correctness of that number, but I want to put up to you guys to see if that number seems feasible.  Is there any reason I can't I put a 70 mil trace on each side?

And, in contrast - this works perfectly if I use a Nano as a slave instead of a tiny. 

Code:

#include "Wire.h"                 
#define I2C_SLAVE_ADDR  0x26           
#define Sensor_PIN  3
int pressure;

void setup(){
  pinMode(Sensor_PIN,INPUT);
  Wire.begin(I2C_SLAVE_ADDR);     
  Wire.onRequest(requestEvent);
}

void loop()
{
}


void requestEvent()
{
  pressure=analogRead(Sensor_PIN);
  byte plow=lowByte(pressure);
  byte phi=highByte(pressure);
  byte data[]={plow, phi};
  Wire.write(data, 2);
  }

its here - http://playground.arduino.cc/Main/WireLibraryDetailedReference -

check requestFrom(address, count);

Thanks for pointing me in that direction.  Between that, and plagerizing other code here from the forum (http://forum.arduino.cc/index.php/topic,160680.0.html), I now have a pair of sketches that work, at least.  Despite it's function, I'm not fond of this code on the slave.

First, here's the master code so you can see it.

Code:

#include "Wire.h";
int ATtinyAddress=0x26;
unsigned long marktime;

void setup()
{
  Wire.begin();
  Serial.begin(9600);
}


void loop(){
  if (millis()>marktime)
  {
    byte hb;
    byte lb;
    Wire.requestFrom(ATtinyAddress,2);
    if (Wire.available())
    {
      lb=Wire.read();
      hb=Wire.read();
    }
    int pressure=word(hb,lb);
    Serial.println (pressure);
    marktime+=1000;
  }
}

Here's the slave code that works.

Code:

#include "TinyWireS.h"                  
#define I2C_SLAVE_ADDR  0x26            
#define Sensor_PIN  3
boolean firstbyte = true;

void setup(){
  pinMode(Sensor_PIN,INPUT);
  TinyWireS.begin(I2C_SLAVE_ADDR);      
  TinyWireS.onRequest(requestEvent);
}

void loop(){
}


void requestEvent()
{
  int pressure=analogRead(Sensor_PIN);
  byte plow;
  byte phi;

  if(firstbyte == true)
  {     // on the first byte we do the math
    plow=lowByte(pressure);
    firstbyte = false;      //so next time though we send the next byte    
    TinyWireS.send(plow);
  }
  else
  {
    phi=highByte(pressure);
    TinyWireS.send(phi);
    firstbyte = true;
  }
}

I don't understand why this code doesn't work.  What purpose does the boolean firstbyte serve in the above sketch?

Code:

void requestEvent()
{
  int pressure=analogRead(Sensor_PIN);
  byte plow;
  byte phi;
  plow=lowByte(pressure);
  phi=highByte(pressure);
  TinyWireS.send(plow);
  TinyWireS.send(phi);
}

I'm trying to use an ATtiny85 to read a MPX5010DP Freescale Pressure Sensor, then send the reading back to an UNO via I2C.  It's just an analog read of the sensor.
I've looked at a number of examples, and this is a far as I've gotten with it.  I can read the pin, map the 0-1023 reading down to 0-255 and send it as a byte using the below pair of sketches.

On the UNO:

Code:

#include "Wire.h";
int selection=0;
int ATtinyAddress=0x26;
unsigned long marktime;

void setup(){
  Wire.begin();
  Serial.begin(9600);
}
void loop(){
  if (millis()>marktime)
  {
  Wire.requestFrom(ATtinyAddress,1);
  while(Wire.available())
  {
    byte v = Wire.read();
    Serial.println(v);
  }
  marktime+=1000;
  }
}

on the ATtiny85

Code:

#include "TinyWireS.h"                 
#define I2C_SLAVE_ADDR  0x26           
#define Sensor_PIN  3

void setup(){
  pinMode(Sensor_PIN,INPUT);
  TinyWireS.begin(I2C_SLAVE_ADDR);     
  TinyWireS.onRequest(requestEvent);
}

void loop(){
}

void requestEvent()
{
  int pressure=analogRead(Sensor_PIN);
  byte pbyte=map(pressure,0,1023,0,255);
  TinyWireS.send(pbyte);
}

I'd like the full resolution of the Tiny, though.  I know I can use lowByte & highByte to get a pair of bytes, and I know I can word() the two back together once I have them on the UNO.
I'm lost at the part of requesting and receiving two bytes, instead of one, and assigning them usable values on the UNO side.

I'm starting a new thread, as the other thread seems to have died out.

I followed the steps here:  http://arduino.cc/forum/index.php/topic,94140.0.html

I am able to get the mouse cursor to move to a specific location on the screen, as expected.  I am unable to get the Mouse.click() command to click, though.  Has anyone else used this modified HID.cpp file successfully?

I was able to get the cursor to stop moving to 0,0 upon Mouse.click();
In the HIP.CPP, I found

Code:

void Mouse_::click(uint8_t b)
{
_buttons = b;
  move(0,0,0);
_buttons = 0;
  move(0,0,0);
}

and changed it to

Code:

void Mouse_::click(uint8_t b)
{
_buttons = b;
// move(0,0,0);
_buttons = 0;
// move(0,0,0);
}

However, I am still not getting a click in absolute mode.  Any ideas?

I was able to use this example to successfully get the mouse to move to a specific location.  It works exactly as expected, until  I follow this with

Mouse.click();

The mouse moves to the extreme upper left hand corner of the screen before clicking instead of remaining where I put it.
Am I overlooking something?

Very impressive!

Thanks to you guys for your tips.  Just using the skip brought me down to 7740.

Eliminating the library altogether brought it down to 7474, but introduces some flaky behavior.  The sensor will stay, mostly, at 79.91 (accurate), but will jump to an absurd number very briefly then immediately back to 79.91.  I'm guessing that I need to slow my sample rate of the sensor down to allow it time to reset?

There doesn't seem to be a huge amount of code there, so I guess you're using some hefty libraries. Do any of them provide functionality that you don't need that could be conditionally compiled out?

I'm not sure what you mean by "conditionally compiled out". 

I did consider removing the EEPROM write to save the setpoint, just designate a value for the setpoint to be every time I reset and change the value each time.  That only brought the code down to 7,980.

Code:

const int DS18S20_Pin=1;
const int ssrPin=0;
const int upPin=9;
const int downPin=10;
const int Setpoint_address=0;

At least some of these could be bytes.

I tried changing all of them as const int, int, and byte.  Byte actually used more space that const int.

Code:

  for (int i = 0; i < 9; i++)
  {
    data[i] = ds.read();
  }

The index is an int?

I don't know.  That's what the DS18B20 example has; I don't know enough to try anything else. 
Do you have a suggestion?

Code:

  float tempRead = ((MSB << 8) | LSB);

Shifting and oring two bytes does not produce a float.

Again, straight from the example code.  I'm receptive to any suggestions.


All in all, I really can't complain.  I'm still new enough at this that I'm shocked at what can be accomplished with such a small investment. The chip was about $2.50, the display about $4, the sensor was $1, and the power supply was about $4.  By the time I add buttons, wires, some capacitors and an enclosure of some sort, I'll be I still come in under $15. 

I've got a similar setup on a Mega328, but that's got all the room in the world in comparison.  I'm just curious how much one can get out of the Tiny.

How good are you at fixed-point (fractional) math?

Completely illiterate.