Lil' Blackbox

General => Hardware => Topic started by: Rx7man on April 18, 2015, 11:02:27 PM

Title: Since I requested this section :P
Post by: Rx7man on April 18, 2015, 11:02:27 PM
For the current scope of this project, the VGT control, and the next 'add-on', we know we're going to need a CAN bus shield, and possibly a stepper driver if we do an AFC delete.. would the Uno be capable of this?


So far for inputs I'm looking at
Crank sensor
EGT
MAP
EGP
TPS
(I'd love to find a way to put a TPS sensor on the fuel rack too)
Coolant temp
Intake air temp
Turbo outlet temp (optional)
Turbine speed (through CAN bus?)

I'll try it with the Uno first, and if I have issues I got the Mega 2560 as well.. Would be nice if the 2560 had a bit a higher clock speed, but considering the Holley Commander 950 is only 4mhz we should be able to pull this off


The Due seems to have an impressive clock speed, but the 3.3V inputs would be a limiting factor in automotive applications, and for designing boards too.

Title: Re: Since I requested this section :P
Post by: hakcenter on April 19, 2015, 02:45:49 PM
Ya I really don't know what they were thinking with the 3.3v Due, that just sucks the big one IMHO.


You can check the Wiki here, v1_0 [Lil' Blackbox] (http://wiki.lilbb.com/v1_0)

I'm working on a newer layout, 1.1, that'll have the pullup for the VR ic, and moving a bunch of traces, and adding cap filters to some of the chips just because.

CANBus is already working on my board, it doesn't really take up anymore space, I could put it on the 2nd layer if space is needed but the v1.1 layout has a ton of spare space.

I'm not sure how to have shaft speed && rpm on the same board. You might be able to use FreqCount and Measure at the same time ?? No idea there, otherwise maybe some kind of triggering multiplexing unit we're in control of to measure shaft speed, then measure rpm, etc.

Shaft speed is through the VR sensor on the turbo, its a separate plug, you may not have known. I count it with FreqMeasure on Pin 8, FreqCount library only goes by 1second intervals sucks, not safe to use.

EGT/MAP etc can all be 5v inputs on the ADCs
Title: Re: Since I requested this section :P
Post by: Rx7man on April 19, 2015, 03:00:00 PM
I think the Mega has several interrupt triggered input pins if I'm not mistaken, though at 140,000x per minute you better have efficient code if you don't want to mess everything else up... Perhaps a there's a pulse counter/divider chip that we could divide the pulses by 100 which would make it much more reasonable...

How do these VR sensors work?  Is it kinda like a Hall Effect in the sense it provides an approximate square wave?
Title: Re: Since I requested this section :P
Post by: hakcenter on April 19, 2015, 03:26:49 PM
There's a magnet (which is what the VR ic interfaces) and then a cutout on the shaft. Like how ABS brakes work.

Mega only shows pin 49 for FreqMeasure, so not sure on that.


Maybe it is possible to adjust the library or make another one, that uses the other interrupt change pins, and count those. However the canbus chip connects via pins 10-13
Title: Re: Since I requested this section :P
Post by: Rx7man on April 20, 2015, 01:50:00 AM
well, 140000 RPM = 2.5kHz, which really isn't much for electronics, but if you're approaching the capacity of your processor, it may be best to move it... I'm sure there's a binary counter that we could adapt.. even if it's just divided by a power of 2 (8 bit sounds good for 256), and the logic would be dead simple, just tie the output pin for 8th bit to the input of the arduino  with a rising interrupt and you have the divider..  2.56 kHz becomes 10hz, and we can easily deal with that frequent an interruption :)... I'm going to look for an IC that'll do it.. they're probably dirt cheap..

This looks like a good start TC74HC4040AP Datasheet(PDF) - Toshiba Semiconductor (http://www.alldatasheet.com/datasheet-pdf/pdf/31746/TOSHIBA/TC74HC4040AP.html), and with a couple supporting IC's I think I could make it run without an interrupt capable pin.. an AND gate to control the reset, and an R/S latch to hold the value between reads while the counter continues.. the program would check on every crank pulse to see if the input is high, then trigger a pin to the latch to reset.. I think we could have reasonable resolution with it, but would require 3 IC's since I don't think there are any that do it all in one.. I'll have to think about it longer though.


As for the Due, I think all the high speed chips are predominantly 3V, so it was more of a constraint placed by chip manufacturers than a desired spec from the Arduino designers
Title: Re: Since I requested this section :P
Post by: hakcenter on April 20, 2015, 04:37:34 AM
I haven't had any issues counting up to 2.5khz while still maintaining my 1ms timer, I guess I could run some milis checks to verify timing.

Using FreqMeasure the code isn't on an interrupt, it just counts the rising edge into the icp1, and includes overflows of the 16bit timer gets full ? Never really read into it.

I put my FreqMeasure in the main loop only, count the frequency and average the last 4 measurements. Also update the two timers.

You might want to look into pulseln, for checking other pins input frequencies.
Title: Re: Since I requested this section :P
Post by: Rx7man on April 20, 2015, 08:20:59 AM
I didn't think of PulseIn(),.. here's what the manual says about it
pulseIn()
Description

Reads a pulse (either HIGH or LOW) on a pin. For example, if value is HIGH, pulseIn() waits for the pin to go HIGH, starts timing, then waits for the pin to go LOW and stops timing. Returns the length of the pulse in microseconds. Gives up and returns 0 if no pulse starts within a specified time out.

The timing of this function has been determined empirically and will probably show errors in longer pulses. Works on pulses from 10 microseconds to 3 minutes in length.
Syntax

pulseIn(pin, value)
pulseIn(pin, value, timeout)


it sounds like it waits (probably with a millis timer), which hangs up the rest of the code I'd assume.

I didn't sleep that well last night, brain working, and I came up with this.. only using that toshiba binary counter.
If you put the Bit 7 (/256) output into an input pin, it would stay on for a long time, giving you time to check for it in the crank angle sensor interrupt.. an output would be sent after it's read to reset it... the only problem is it would be slightly inaccurate because of the delay from the time the pin is turned on to the time the arduino sees it and resets it... might not be a big deal though
Title: Re: Since I requested this section :P
Post by: Rx7man on April 21, 2015, 04:19:13 PM
What version of the CAN bus does the VGT need? I see CAN 2.0, and ECAN?

I'm looking at the PIC18F family of microcontrollers from Microchip, and I think I could offload enough stuff onto that chip to be able to still use an UNO board... The PIC18F have built in CAN bus, as well as IO's etc in a DIP package.

How does it work to have one controller 'talk' to the other?  Over I2C? SPI?  How does one controller send data to the other, I'm talking is it a PITA to interface it programatically?


Also, I found a better solution to reading the turbine shaft speed input.. still with a binary counter, but if you take bit 7 for example, you don't need to reset it... in the program code you just have a static boolean value, if the value is the same, you do nothing, if it's different, then you count it as an 'increment'... you will always have a 50% duty cycle off a single pin of the binary counter, which make it work perfect... I'm actually thinking of using this idea (with less bits) for the engine speed, and perhaps even a vehicle speed sensor. 
Title: Re: Since I requested this section :P
Post by: hakcenter on April 21, 2015, 08:39:17 PM
pulseln stuff:

// period of pulse accumulation and serial output, milliseconds
#define MainPeriod 100
long previousMillis = 0; // will store last time of the cycle end
volatile unsigned long duration=0; // accumulates pulse width
volatile unsigned int pulsecount=0;
volatile unsigned long previousMicros=0;

void setup()
{
  Serial.begin(19200);
  attachInterrupt(0, myinthandler, RISING);
}

void loop()
{
  unsigned long currentMillis = millis();
  if (currentMillis - previousMillis >= MainPeriod)
  {
    previousMillis = currentMillis;   
    // need to bufferize to avoid glitches
    unsigned long _duration = duration;
    unsigned long _pulsecount = pulsecount;
    duration = 0; // clear counters
    pulsecount = 0;
    float Freq = 1e6 / float(_duration);
    Freq *= _pulsecount; // calculate F
    // output time and frequency data to RS232
    Serial.print(currentMillis);
    Serial.print(" "); // separator!
    Serial.print(Freq);
    Serial.print(" ");
    Serial.print(_pulsecount);
    Serial.print(" ");
    Serial.println(_duration);
  }
}

void myinthandler() // interrupt handler
{
  unsigned long currentMicros = micros();
  duration += currentMicros - previousMicros;
  previousMicros = currentMicros;
  pulsecount++;
}

Precise frequency measurements with Arduino microcontroller (http://arduino.datamaster2003.com/f-measurements.htm)

If you want, maybe tomorrow I can run get the laptop and add a milis to my arduino, to verify speed and timing, and ass-haulingness

I don't know if it is wise to add another microprocessor on there, unless you plan to program it off PCB and land it back on ?
Title: Re: Since I requested this section :P
Post by: Rx7man on April 22, 2015, 08:39:54 AM
OK, I'll have to look at that a little harder and see if it'll work.. I downloaded a whack more datasheets, and a new digikey catalog, mine was getting old.

What kind of wave output does the VR sensor give?  does it need much preconditioning outside of perhaps a couple resistors and a clamp diode before being fed to an input?  We could probably even read it with an analog input if we didn't care about accuracy too much... it may be an option, though 10 bit resolution leaves a little to be desired.


I'll try and get a list for my Digikey order for you to look over and see if I'm missing anything evident.. I can probably recycle some stuff like small caps, etc from dead stereos..
Some stuff like the binary counters, and/nad/xor gates, op-amps, NPN transistors 5v zeners, and all the basics I'll just get a bunch of so I'm set for a while
What chip are you using for the CAN bus and I'll add that to the list
Title: Re: Since I requested this section :P
Post by: Rx7man on April 22, 2015, 09:57:16 AM
Speaking of analog frequency counters...
Check this out.. specificaly for VR sensors, I think that would be the best way to read the turbine shaft speed for now at least... just need an analog input.. RPM accuracy with 10 bits would be +-150 RPM, but seriously if it's +-1000 (there's other inaccuracies) it'll be close enough to do what I need it to.

www.ti.com/lit/ds/symlink/lm2907-n.pdf

Best part of it is it doesn't take many CPU cycles to figure it out, and you could have the identical circuit with a different scaling factor for RPM as well..  the decoding would just be analoginput*scalefactor = RPM, and it could be read at any time, it'll be spike-free since it's analog, which naturally incorporates averaging, and doesn't need interrupts (you said you really like to save that one pin with an interrupt didn't you?)

There's always more than one way to skin a cat, and looking at all the options (maybe trying them all?) is good.

Benefit to the binary counter method? very high accuracy at high RPM's, but had a long delay at low RPM, doesn't take too may CPU cycles and doesn't need an interrupt though, but must poll the pin at at least double the rate of your peak input frequency... Only requires one CHEAP chip ($.58) and one digital input pin

Benefit to the LM2907 analog?  Can read the voltage any time you want the RPM, requires virtually no CPU time, easy to scale, does require an analog input (we're going to be needing a LOT of those, maybe more than are available), Suffers from poor accuracy with 1024 bits + LM2907 non-linearity.
Title: Re: Since I requested this section :P
Post by: hakcenter on April 22, 2015, 10:46:55 AM
Ya no good if its not linear, requires math on top of the problematic multiplexed ADCs on the Arduino. You usually loose 1-2ms on ADC reads on the arduino, because you have to read them twice. Once usually reads the last pin depending on spe ed of your code, so you have to read it twice and wait for the gate switch overs.

Good idea though... I would use it for non-essentials, like RPM, and update every 10ms maybe even as slow as 25ms

I'm using an MCP2551 and MCP2515
Title: Re: Since I requested this section :P
Post by: Rx7man on April 22, 2015, 11:30:25 AM
Exactly, RPM being off by a bit wouldn't hurt much, except perhaps at idle if it's too far off.. the the turbine shaft speed I think it would be perfectly suitable though and really help the simplicity.. ditto for the vehicle speed sensor input if we use one
Title: Re: Since I requested this section :P
Post by: hakcenter on April 22, 2015, 12:15:22 PM
Problem is VR sensors are not Hall, and increase voltage and noise.

(http://www.daytona-twintec.com/sensor_data/CKP_Sensor_Waveforms.gif)

I wouldn't count the shaft speed with anything less than a dedicated IC. I use the max9924 to do all the dirty work and output a nice and safe 5v frequency pwm
Title: Re: Since I requested this section :P
Post by: Rx7man on April 22, 2015, 05:26:37 PM
I think a dedicated IC for the turbine shaft speed is good, I think our trucks already have a hall effect sensor for engine RPM so less preconditioning will need to be used with it, and since it's only going to be ~200 hz peak, it's not going to be hard to deal with... I'll look up that max9924.

Which of the MCP2551 or 2515 do you prefer?  Datasheet doesn't say what input mode it uses.. they say a differential, so it makes it sound like RS485.. the 16 pin I think says it uses SPI
Title: Re: Since I requested this section :P
Post by: hakcenter on April 22, 2015, 07:52:48 PM
They work together, one takes your SPI outputs to the other, last one sends CAN on the way out.

I never looked up much, but you can check the seeed schematic.
Wiki : CAN-BUS Shield - Wiki (http://www.seeedstudio.com/wiki/CAN-BUS_Shield)
Eagle File : http://www.seeedstudio.com/wiki/images/7/75/CAN-BUS_Shield_v0.9b_20120621.zip
Title: Re: Since I requested this section :P
Post by: Rx7man on April 22, 2015, 09:52:42 PM
ah, OK.. and is this a bidirectional thing? can you read the position of the VGT through it?

this is a steep learning curve for me, I'm doing lots and lots of research on it though.

How do you etch boards?.. more importantly, how do you print the mask and drill the holes?
Title: Re: Since I requested this section :P
Post by: hakcenter on April 22, 2015, 10:08:12 PM
I've never actually etched my own boards, just engineer something in eagle and proto it.

I probably should make this a wiki so that people can understand the chain of command on the turbo. The Holset VGT's have 2 plugs, 1 4pin & 1 2pin (in a 3 pin housing).

The 4 pin is the main connector, it is power / ground / can low / can high
The 2 pin is the VR sensor connector, it is VR+ and VR-

When talking to the turbo, it doesn't do anything on its own, except when it hasn't received a canbus command for a vein position, it will default to vein position 0 if it hasn't received a message in 5-10ms.

You can only talk to the turbo through canbus, and there is some other communication information, Steed knows some info I don't know if he will join.

Only 2 things I know that you can tell the turbo to do is,
Vein position
Re-calibrate position (this one is wonky sometimes the turbo shuts off afterwards sometimes nothing)

From what Steed told me, what the turbo can tell you is
Feedback from backpressure (some type of measurement the motor force used to maintain position of sorts)
Some turbos have a temperature probe ??

So in a sense, just talking to the turbo its only 1 direction, but CANBus is basically like your old vampire coax networks, where everything is connected, has addresses, but its more modern in that, you designate what you want to talk to, and everything hears it but only the appropriate device will respond given that the command you send is good.


The VR sensor is a plug all on its own, completely independent of the controller housing. I imagine some manufactures use it, but most likely a lot have a harness connection that goes no where.
Title: Re: Since I requested this section :P
Post by: Rx7man on April 23, 2015, 12:38:11 AM
OK, good info!.. if I could get some sort of info about pressure back from the turbo it would save me a big chunk of change, even if the calibration isn't known or great (can always put a mechanical gauge on it and figure it out), and same thing for EGT if it has it.
Wow, it wants updates every 5-10 ms??? that's darned demanding!.. and the defaulting to position 0 is kinda stupid.. should just stay put!
Title: Re: Since I requested this section :P
Post by: hakcenter on April 23, 2015, 01:13:25 AM
Safety factor, to default open good sir.

The back pressure was the first thing I asked Steed about, and he said the information was really only helpful in finding if there was soot buildup not for actual backpressure.

I'm not sure where the temp probe, if 351's have it on the board. When I asked Steed he made it more about engine coolant temp, but when I had my board open I never saw a thermistor so maybe different boxes.. might have one ??? No idea.

Yep, its a demanding controller. But you don't have to update position, you can continuously send the original over and over, and it just won't move. Which is where my code has honestly taken me. I don't see the need to micromanage the turbo, certainly going to blow the controller faster by making it constantly move.

I was working on top end code, to try to move away from my staging, but I can't find a reliable way to keep it under 130k rpm, unless its already in the 400 range.
Title: Re: Since I requested this section :P
Post by: Rx7man on April 23, 2015, 08:04:47 AM
Oh, 0 is fully open? alright.   I will update the CAN bus every in the Void loop, but only update the variable every once in a while.

Is there a good PID library around?  I made one in VB but it was way too complex to be used on a microcontroller
Title: Re: Since I requested this section :P
Post by: hakcenter on April 23, 2015, 09:37:55 AM
Haven't really looked or used one at all
Title: Re: Since I requested this section :P
Post by: Rx7man on April 23, 2015, 04:09:44 PM
I found one, may or may not have what I want/need, but I might hack it apart and make it do what I want it to... I think it would be the best way to control the VGT / boost level.

I was also thinking in the spirit of keeping it responsive, just set a minimum step size for the VGT but update as often as you loop through it.. with a correctly spaced step size it will naturally not move often... this is especially true in the closing direction, you want it to open responsively at all times though.
Title: Re: Since I requested this section :P
Post by: Rx7man on April 26, 2015, 12:05:29 AM
Have you ever hooked up an ammeter to the power wire of the VGT to see what it draws for current?  I was thinking about that fried board on CF and thinking perhaps it would be a good idea to put a fuse in there that's not rated too high.. perhaps a 5 or a 7.5 amp?.. better to blow the fuse than fry the board.. them things ain't cheap!
Title: Re: Since I requested this section :P
Post by: hakcenter on April 26, 2015, 06:33:24 AM
Around ~10, pushing from one extreme to the other, (0 > 1000 | 1000 > 0)

I have mine on a bosch fuel relay 20amp.
(https://w05.dealerconnect.chrysler.com/service/mds2002/serviceInfo/en_US/80019913.gif)
Title: Re: Since I requested this section :P
Post by: Rx7man on April 26, 2015, 02:33:14 PM
I have a pile of those.. certainly a good idea to run one.. Some models of those relays have 87 and 87a connected both as normally open, but not tied together.
Title: Re: Since I requested this section :P
Post by: Rx7man on April 29, 2015, 12:08:18 AM
I just looked into the LM2907, it doesn't need preconditioning to be run on a VR sensor (YAY!!).. and here I was, I had already had a MAX9927 already drawn up.. Oh well.. if nothing else I'm getting the hang of Eagle

I gotta say though.. what are the people smoking when they're drawing up these libraries??  They seem to try and deliberately make it impossible to have a nice schematic!..   Looking at the MAX9927, it has 2 VR sensor inputs.. the two positive inputs were above the two negative inputs, so it's impossible to not have criss crossed wires.. rather than have the first positive over the first negative, followed by the second pair which would just look nice.

I also see that Texas Instruments will offer free samples.. might be something to test out :>

As far as finding out the component values I may need a bit of a hand.. not all datasheets give you good info
Title: Re: Since I requested this section :P
Post by: hakcenter on April 29, 2015, 12:53:51 AM
9924 for a single input.
Title: Re: Since I requested this section :P
Post by: Rx7man on April 29, 2015, 01:57:12 AM
yes, but the 9924 is only a signal conditioner... the 2907 is a frequency to voltage convertor, which suits our application well, and it doesn't need nearly as many passive components around it than the 9924 does as far as I can tell.

I went with the 9927 because it may be handy to use with the Vehicle speed sensor at a later date, granted it'll probably need a different set of passive components to deal with the lower frequency
Title: Re: Since I requested this section :P
Post by: hakcenter on April 29, 2015, 10:46:45 AM
In A2, it needs 2x 10k resistors input and a cap between them. Power filters if you want. If you can afford the gate speed on the ADC multiplexers then ya go for it.
Title: Re: Since I requested this section :P
Post by: Rx7man on April 29, 2015, 12:36:05 PM
it will have to be seen how all that works out in the real world.

I remember working on a PLC, an old Allen Bradley that was SOOO slow, (an SLC3 I think it was, and the clock speed was probably well under 1mhz, timer resoluteion was 1/100th of a second at best I think) and the problem was it had to apply glue based on a timer, but the timers were all over the place, and the loop iterations weren't consistent, so the glue patterns were always in the wrong place.. In the end I made a counter that counted every loop and determined how fast the computer was running at that instant, and compensated the glue pattern timers accordingly.. it was a nightmare, and by the time they paid me it would have been cheaper to put a new PLC into the machine.. this was all done in Ladder logic
Title: Re: Since I requested this section :P
Post by: hakcenter on April 29, 2015, 03:15:40 PM
Been working in my truck for over 3 months ??
Title: Re: Since I requested this section :P
Post by: Rx7man on April 29, 2015, 04:33:01 PM
I have no feel for how fast an arduino is, never worked with one yet.  however the Holley box I have has a 4 mhz processor and it seems to do fine, and it has to control ignition timing too which is very sensitive..
Title: Re: Since I requested this section :P
Post by: hakcenter on April 29, 2015, 05:18:51 PM
I'll see if I can get some milli's for you
Title: Re: Since I requested this section :P
Post by: hakcenter on April 29, 2015, 06:28:16 PM
Here's some millis for you..

Here's where I pushed slightly on the go pedal

POS : 600 | RPM :  69105 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 600 | RPM :  72548 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 600 | RPM :  76309 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 600 | RPM :  83640 | Mode : Normal
1 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 600 | RPM :  87210 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 600 | RPM :  90270 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 600 | RPM :  93075 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 600 | RPM :  95562 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 600 | RPM :  97857 | Mode : Normal
1 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 600 | RPM : 100088 | Mode : Normal
2 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 592 | RPM : 102192 | Mode : Normal
1 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 582 | RPM : 104614 | Mode : Normal
1 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 545 | RPM : 113922 | Mode : Normal
2 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 520 | RPM : 120042 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 470 | RPM : 125205 | Mode : Normal
1 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 100 | RPM : 124695 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 112 | RPM : 118639 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 258 | RPM : 104040 | Mode : Normal
1 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 349 | RPM :  93394 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 449 | RPM :  84724 | Mode : Normal
1 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()
POS : 549 | RPM :  78285 | Mode : Normal
0 ms |loop() || 0 ms |keep_time() || 0 ms |calculate_vein_position() || 0 ms |set_turbo_position()


Full log as attachment
Title: Re: Since I requested this section :P
Post by: Rx7man on May 28, 2015, 09:42:02 PM
Well, I think I'm going to order in that SmartLynx L6470 based board for a test run, and then at some point build my own which will have all the rest of the IC's I think I'll need.. like the thermocouple and frequency chips... Also thinking of making it so it mounts under the Arduino rather than on top, just need to put long pin headers on it... One problem, it'll be a big board, and I don't think Eagle will let me design it in the free version
Title: Re: Since I requested this section :P
Post by: hakcenter on May 28, 2015, 11:02:15 PM
I think eagle does up to like 4x4" and 4 layers ? maybe only 2 layers.. been awhile