PocketNC / LinuxCNC configuration

Few months ago I got an PocketNC V2-50 machine.

One issue that I’m having is that it’s rewinding it’s B-axis back. And that takes a lot of time. On top of that, there is a limit of -9999 +9999 degrees that I can rotate. Any value over those, the machine will do an rewind. This is configured to Fusion post-processor. I have had small medical parts that rewind 3 times in a part and this quickly multiplies to hours of time when I have done multiple parts. So this is something that I would like to solve.

I read from [1] that there is an configuration item called WRAPPED_ROTARY in LinuxCNC. So I tested it, simply changed it from my PocketNC configuration, see image below. After tests, I got either positive or negative rotation ok, not both. Other direction always gave “B-axis outside of negative (or positive) limits” error. Based on [2] I increased MAX_LIMIT and MIN_LIMIT to 1e99 and -1e99. After that errors were gone. Here is my current configuration:

Testing with MDI-commands to see how this works.

1. Home
2. MDI commands as follows:

1) G90 B0 F1000

2) G90 B350 F1000 // makes an 350 degree motion counterclock to absolute position 350

Both DRO and MDI at the same until this position, eg. B position is 350 as to be expected.

3) G90 B340 F1000 // makes again an 350 degree motion counterclock to obtain absolute position 340. Coordinates 700 at this point (360 + 340 = 700 == correct)

4) G90 B0 F1000

When we then move to 0, then the way machine is configured from the factory it would unwind all the way back, almost two full rotations clockwise. But with this new configuration, movement is only 20 degrees and that is what we really want. Position is 720 as is 2×360 as 2 full rotations (2×360).

So this is all good. And if we want to another way, eg. clockwise, we just output negative signs:

5) G90 B-10 F1000

This moved clockwise 350 degrees to position B-10 and new DRO is 370.

6) G90 B-0 F1000

This resulted 10 degree motion in clockwise and DRO is reading 360 as is ok.

So in summary we have an working unlimited rotary axis. We need to discuss with PocketNC support if calibration tables would be valid in this case as it seems from the post [3] that they might not be.

Fusion Post configuration

But I can’t figure how to modify Fusion 360 post processor to output to output my g-code correctly.

I tried to run small tests of rotary toolpaths with Fusion. I have subscribed to Manufacturing Extension and would like to utilize that handy rotary toolpath. I managed to get G-code partially working. Another direction is working and another direction is not. Depending on my configuration, either climb-milling or conventional-milling is working ok.

Depending on axis configuration on Fusion Post I can get either Climb milling or Conventional milling working.

Lets look at Conventional Rotary toolpath start:

%
(AXIS,stop)
(1001)
N10 G21
N15 G90 G94 G40 G17 G91.1
N20 G53 G0 Z0.
(ROTARY1 CONV)
N25 G49
N30 M5
N35 G53 G0 X63.5 Y63.5
N40 M0
N45 T18 M6
N50 S40000 M3
N55 G54 G0
N60 G0 A0. B-90.
N65 M7
N70 G1 X0.599 Y48.814 F10000.
N75 G43 Z24.993 H18
N80 G1 A0. B-90.
N85 X0.295 Z12.3 F10000.
N90 X0.292 Z12.203 F400.
N95 Z10.3
N100 X0.279 Z10.213 F800.
N105 X0.238 Z10.128
N110 X0.17 Z10.059
N115 X0.087 Z10.015
N120 X0. Z10.
N125 B-87.035 F916.73
N130 Z9.998 B-82.192
N135 Z9.997 B-82.185
N140 Z10. B-80.607
N145 Z9.997 B-79.265
N150 B-79.258
N155 Z10. B-76.933
N160 Z9.997 B-76.03
N165 B-76.022
N170 Z10. B-74.166
N175 Z9.996 B-72.696
N180 B-72.688
N185 Z10. B-70.493
N190 Z9.996 B-69.273
N195 B-69.266
N200 Z10. B-67.738
N205 Z9.996 B-65.858
N210 B-65.851
N215 Z10. B-64.064
N220 Z9.996 B-62.443
N225 B-62.436
N230 Z10. B-60.391
N235 Z9.995 B-58.992
N240 B-58.985
N245 Z10. B-57.636
N250 Z9.995 B-55.52
N255 B-55.512
N260 Z10. B-53.963
N265 Z9.996 B-52.054
N270 Z9.995 B-52.047
N275 Z10. B-50.289
N280 Z9.997 B-48.912
N285 B-48.905
N290 Z10. B-46.616
N295 B-39.269
N300 Z9.997 B-38.294
N305 B-38.287
N310 Z10. B-36.515
N315 Z9.997 B-34.082
N320 Z9.995 B-31.005
N325 Z10. B-29.252 F915.92
N330 Z9.996 B-27.566
N335 B-27.559 F917.14
N340 Z10. B-25.579 F915.85
N345 Z9.996 B-24.144
N350 B-24.137 F917.13
N355 Z10. B-22.824 F915.8
N360 Z9.996 B-20.764
N365 B-20.757 F917.12
N370 Z10. B-19.15 F915.57
N375 Z9.996 B-17.428
N380 B-17.421 F917.11
N385 Z10. B-15.477 F915.38
N390 Z9.996 B-14.135
N395 B-14.128 F917.1
N400 Z10. B-12.722 F915.11
N405 Z9.996 B-10.899
N410 B-10.892 F917.07
N415 Z10. B-9.119 F914.51
N420 Z9.996 B-7.713
N425 B-7.706 F917.06
N430 Z10. B-6.364 F913.71
N435 Z9.996 B-4.599 F912.81
N440 B-4.592 F917.06
N445 Z10. B-2.691 F910.26
Up to this point rotation is wrong, it’s climb milling. B is decreasing up until this point and sign is negative. Why is this, that is something I don’t know ?

From this point onwards it’s conventional milling as supposed to be. B is increasing and sign is positive.

N450 B12.916 F916.71
N455 Z9.997 B13.877 F915.76
N460 B13.884 F916.99
N465 Z10. B15.671 F915.77
N470 Z9.997 B17.156
N475 B17.163 F917.
N480 Z10. B19.344 F915.98
N485 Z9.997 B20.542
N490 B20.549 F917.02
N495 Z10. B22.762 F916.03
N500 B26.023 F916.72
N505 Z9.996 B27.558 F915.89
N510 B27.565 F917.14
N515 Z10. B29.696 F916.02
N520 Z9.995 B31.009
N525 B31.016 F917.14
N530 Z10. B32.451 F916.03
N535 Z9.995 B34.481
N540 B34.489 F917.15
N545 Z10. B36.125 F916.07

...

N10560 Z9.996 B265.418
N10565 B265.425
N10570 Z10. B267.169 F916.54
N10575 Z9.997 B268.482
N10580 B268.489 F917.05
N10585 Z10. B270. F916.53
N10590 X-0.086 Z10.015 F800.
N10595 X-0.17 Z10.059
N10600 X-0.238 Z10.128
N10605 X-0.279 Z10.213
N10610 X-0.292 Z10.3
N10615 Z12.203 F10000.
N10620 X-0.598 Z24.993 F10000.
N10625 G49
N10630 M9
N10635 G49
N10640 G53 G0 Z0.
N10645 G53 G0 X63.5 Y63.5
N10650 A0. B0.
N10655 M30
(AXIS,stop)
%

After this program is run, there is only about 45 degree rotation to zero, no rewinding. DRO is reading 2520 and that is ok since that is 7 x 360.

Motion is somewhat jerky and I suspect this is due to G61 and/or G64 path blending or excact stop and axis kinematics configured start/stop accelerations. I need to look into this later, I have seen videos with LinuxCNC configured ok for rotational axis and smooth milling but this seems to be complicated subject.

Here’s Climb milling toolpath that is not at all working:

%
(AXIS,stop)
(1001)
N10 G21
N15 G90 G94 G40 G17 G91.1
N20 G53 G0 Z0.
(ROTARY1 CLIMB 2)
N25 G49
N30 M5
N35 G53 G0 X63.5 Y63.5
N40 M0
N45 T18 M6
N50 S40000 M3
N55 G54 G0
N60 G0 A0. B-90.
N65 M7
N70 G1 X-0.598 Y48.814 F10000.
N75 G43 Z24.993 H18
N80 G1 A0. B-90.
N85 X-0.294 Z12.3 F10000.
N90 X-0.292 Z12.203 F400.
N95 Z10.3
N100 X-0.279 Z10.213 F800.
N105 X-0.238 Z10.128
N110 X-0.17 Z10.059
N115 X-0.086 Z10.015
N120 X0. Z10.
N125 Z9.996 B-91.516 F916.53
N130 Z9.997 B-91.523 F917.05
N135 Z10. B-93.604
N140 Z9.996 B-94.58
N145 B-94.587
N150 Z10. B-96.359 F916.55
N155 Z9.999 B-109.744
N160 Z9.996 B-110.899
N165 B-110.906 F917.06

…

N10480 Z9.996 B-82.29
N10485 B-82.297 F917.08
N10490 Z10. B-84.414 F916.57
N10495 Z9.996 B-85.418
N10500 B-85.425
N10505 Z10. B-87.169
N10510 Z9.997 B-88.482
N10515 B-88.489
N10520 Z10. B-90.
N10525 X0.086 Z10.015 F800.
N10530 X0.17 Z10.059
N10535 X0.238 Z10.128
N10540 X0.279 Z10.213
N10545 X0.292 Z10.3
N10550 Z12.203 F10000.
N10555 X0.598 Z24.993 F10000.
N10560 G49
N10565 M9
N10570 G49
N10575 G53 G0 Z0.
N10580 G53 G0 X63.5 Y63.5
N10585 A0. B0.
N10590 M30
(AXIS,stop)
%

B-motion does not move in correct direction.

Between these lines

N125 Z9.996 B-91.516 F916.53
N130 Z9.997 B-91.523 F917.05

B-axis rotates almost full 360 degrees clockwise. As we saw from earlier g-code, correct behaviour would be B to decrease while sign is negative to have correct motion.

PocketNC Fusion360 PostProcessor has an line

// var previousABC = new Vector(0, 0, 0); // previous ABC position if maintained in post, don't define if not used

That could be related or not, I tried to uncomment it but did not understand yet what it does by reading the post-processor code.

To understand better, I checked LinuxCNC docs and they have this comment regarding WRAPPED_ROTARY:

WRAPPED_ROTARY

When this is set to 1 for an ANGULAR axis the axis will move 0-359.999 degrees. Positive Numbers will move the axis in a positive direction and negative numbers will move the axis in the negative direction.

To be sure, I looked into LinuxCNC code:

interp_convert.cc:

CHKS((block->b_flag && settings->b_axis_wrapped &&
(block->b_number <= -360.0 || block->b_number >= 360.0)),
(_("Invalid absolute position %5.2f for wrapped rotary axis %c")),
block->b_number, 'B');

interp_find.cc:

if(block->b_flag) {
if(s->b_axis_wrapped) {
CHP(unwrap_rotary(BB_p, block->b_number,
block->b_number - s->BB_origin_offset - s->BB_axis_offset - s->tool_offset.b,
s->BB_current, 'B'));
} else {
*BB_p = block->b_number - s->BB_origin_offset - s->BB_axis_offset;
}
} else {
*BB_p = s->BB_current;
}

And here seems to be actual calculation:

interp_find.cc:
/* Find the real destination, given the axis's current position, the
   commanded destination, and the direction to turn (which comes from
   the sign of the commanded value in the gcode).  Modulo 360 positions
   of the axis are considered equivalent and we just need to find the
   nearest one. */

int Interp::unwrap_rotary(double *r, double sign_of, double commanded, double current, char axis) {
    double result;
    int neg = copysign(1.0, sign_of) < 0.0;
    CHKS((sign_of <= -360.0 || sign_of >= 360.0), (_("Invalid absolute position %5.2f for wrapped rotary axis %c")), sign_of, axis);
    
    double d = floor(current/360.0);
    result = fabs(commanded) + (d*360.0);
    if(!neg && result < current) result += 360.0;
    if(neg && result > current) result -= 360.0;
    *r = result;

    return INTERP_OK;
}

Here are some tests with PocketNC WRAPPED_ROTARY = 1:

1. Home
2. G90 B-45 F3000 Moves clockwise 315 degrees to reach position 45

1. Home
2. G90 B-315 F3000 Moves clockwise 45 degrees to reach position 315

1. Home
2. G90 B10 F3000 Moves counterclockwise 10 degrees

1. Home
2. G0 G90 B350 F3000 Moves counterclockwise 350 degrees
3. G0 G90 B330 F3000 Moves counterclockwise 340 degrees to reach 330 absolute position

Current Fusion output when Rotary climb is like this:

G0 G90 B-91.000 F3000 – clockwise 270-1=269 degree
G0 G90 B-95.000 F3000 – clockwise 360-4 = 356 degree

So this is not good. Should be

G0 G90 B-95.000 F3000
G0 G90 B-91.000 F3000

to get clockwise rotation of 4 degrees, so a) negative sign (this is ok) and b) decreasing numbers, not increasing. How to modify post processor to obtain this ?

Summary

positive sign = conventional milling, counterclockwise motion

negative sign = climb milling, clockwise motion

If called

a) G0 G90 B-10

b) G0 G90 B-20 # this would result clockwise motion of 350 degrees

c) G0 G90 B-10 # this would result clockwise motion of 10 degrees

Climb milling with clockwise rotation would be obtained with this sort of G-code:

G0 G90 B-359.99

G0 B-350

G0 B-340

G0 B-330

Documents:

[1] LinuxCNC posts discussing WRAPPED_ROTARY-axis: https://forum.linuxcnc.org/10-advanced-configuration/34908-unlimited-rotary-axis?start=10

[2] LinuxCNC configuration options: http://linuxcnc.org/docs/2.7/html/config/ini-config.html#_axis__lt_num_gt_section

[3] PocketNC Google Group post regarding B-axis rollover: https://groups.google.com/g/pocket-nc/c/JWkws7rWxL4/m/q4fwT6RqBQAJ

https://knowledge.autodesk.com/support/fusion-360/learn-explore/caas/sfdcarticles/sfdcarticles/How-to-make-a-3-axis-post-processor-from-the-HSM-post-processor-library-support-4-or-5-axis-motion.html

http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g90-g91

https://www.mail-archive.com/machinekit@googlegroups.com/msg01772.html

Executive summary

It was found that BalenaFIN boards did not perform well in elevated ambient temperatures.

Balena did an root cause analysis and issued an fix.

We did some tests (described in this post) that verified that fixed boards work ok at least in ~73 C ambient temperature for 8 hours.

Description of project

It was found that our BalenaFIN based products are not working correctly at elevated ambient temperatures. This was also the case in deployed installations at our client sites where elevated temperatures are often found due to hot process environment. During summer 2020 we were forced to add extra cooling to deployed devices at field as quick fix for the problem.

As soon as our clients reported possible temperature problems, we did small change to our deployed software to read internal temperature from BalenaOS  /sys/class/thermal/thermal_zone0/temp and send it to our cloud. So we have temperature data from failed units and can thus compare readings.

These pre-fix boards have failed when this internal temperature was between 60-70 C. Unfortunately we don’t have any ambient measurement data available for those deployed pre-fix boards.

After extended testing Balena found an issue on their board that affected board stability at high temperatures. An resistor value was found to be wrong and thus resulted to wrong voltage levels that resulted in internal components being powered off. Based on testing Balena changed the resitor value to more suitable value. Detailed root-cause analysis can be found from https://www.balena.io/blog/usb-issue-rca/.

We ordered new boards immediately when they were available after Balena released information about this fix.

Test aim

• Phase1
  • We shall test that ambient temperature of ~70C is not an issue for BalenaFIN by heating bare BalenaFIN in heat-chamber to ~70C ambient and log the performance for one full workday (8h).
• Phase 2
  • If phase 1 succeeds, we shall test with ethernet sensor connected
• Phase 3 (optional)
  • When we have new batch of mPCIe modems, we should test with the modem we are using to verify out also mPCIe working

Test setup

• BalenaFIN board (new fixed revision, received from Balena 2020/08)
• Memmert UM200 laboratory heat-chamber
• Fluke T3000FC temperature logger
• IFM AL1350 industry IoT ethernet-board
• IFM TV7105 IO-LINK temperature probe
• AIM TTi laboratory bench power supply with 24V output
• Software to read and log /sys/class/thermal/thermal_zone0/temp temperature reading

Test decription

Phase 1: Bare BalenaFIN – board 8 h

• Laboratory heat-chamber was heated to approximately 73C
• BalenaFIN was put inside chamber to FR4 base
• Fluke-temperature probe was put inside chamber and logging was started
• BalenaFIN started to send temperature values to cloud and these were monitored and logged for 8 hours.
• Graphs were drawn with ambient temperature from Fluke temperature logger and internal temperatures sent by BalenaFIN and checked that Balena did send temperature to cloud whole time.

Fig 1: Test chamber temperature readings of 73 C during 8 hour test period.

Fig 2: Internal temperatures reported by Balena. About 91 C.

It was found that Balena worked correctly during this test so proceeded to phase 2.

Phase 2: With ethernet connected, 3 h

• Same setup and test procedure as in phase 1 but heat chamber temperature was measured also with IFM IO-link industrial sensor connected to ethernet. If USB power is missing, this should show in data as per Balena’s report, ethernet bridge is also USB-based.

Fig 3: 3 hour heat chamber temperature and balena internal temperatures. Heat chamber temperature measured with ethernet sensor to see if ethernet is stable.

 

BalenaFIN was found to be correctly sending both values whole time.

Conclusions

We verified that at least BalenaFIN unit we tested was successfully able to withstand 73 C ambient temperature without failing.

So the fix that Balena did seems to be working.

Possible next steps

To replace every distributed board at customer sites with a fixed board and send broken boards back to Balena for RMA repair.

If needed, heat chamber tests with mPCIe modems used in application could be done also.

 

Test time, location and participants

2.-4. Sep. 2020

PalonenLABS Oy workshop, Tampere, Finland

Henry Palonen / PalonenLABS Oy

I have bought few Fluke Connect modules and they seem to work nicely. They allow me to remotely measure voltage, current and temperature. Handy if I just want quickly to measure and possibly log something in our projects. I have also an FC-module for my logging multimeter (Fluke 289) but it’s currently at our “electrical motor-testing cave” so it did not make it to this group photo 🙂

One feature missing is the ability to integrate measurements to my own .Net C# software. So I searched high and low for protocol documentation or programming API for these devices. I didn’t find anything so today I spent few hours to investigate this issue.

Few hours later I’m able to read Fluke V3001 FC voltage module from my own software so success!

Here is how I did it.

As Fluke PC3000 FC adapter seems to present itself to PC as a serial port, I started an serial port sniffer tool and read the communication between PC and original Fluke Connect software.

Here is one capture of where device is discovered and then live view displays data from one voltage module;

<COM7: 20170920141932.813 TX>
id
<COM7: 20170920141932.831 RX>
CR:Ack=0:ID:FLUKE PC3000FC,V01.02.00,0
<COM7: 20170920141932.833 TX>
rfsm 1
<COM7: 20170920141932.844 RX>
CR:Ack=0:RFSM:Radio On MasterRE:M
<COM7: 20170920141939.470 TX>
rfdis
<COM7: 20170920141939.509 RX>
CR:Ack=0:RFDISME:S
<COM7: 20170920141949.062 RX>
ME:D:010000000000
<COM7: 20170920141949.075 TX>
rfebd 01 0
<COM7: 20170920141949.079 RX>
CR:Ack=0:RFEBDME:R:S#=01:DCC=012:PH=19
<COM7: 20170920141949.274 TX>
rfebd 02 0
<COM7: 20170920141949.287 RX>
CR:Ack=2
<COM7: 20170920141952.277 TX>
rfebd 03 0
<COM7: 20170920141952.290 RX>
CR:Ack=2
<COM7: 20170920141955.279 TX>
rfebd 04 0
<COM7: 20170920141955.292 RX>
CR:Ack=2
<COM7: 20170920141958.281 TX>
rfebd 05 0
<COM7: 20170920141958.295 RX>
CR:Ack=2
<COM7: 20170920142001.285 TX>
rfebd 06 0
<COM7: 20170920142001.300 RX>
CR:Ack=2
<COM7: 20170920142004.287 TX>
rfgsid 01
<COM7: 20170920142004.302 RX>
CR:Ack=0:RFGSIDME:R:S#=01:DCC=001:PH=464C554B4520563330303146432C5630322E30312E303000
<COM7: 20170920142004.621 TX>
rfgus 01
<COM7: 20170920142004.644 RX>
CR:Ack=0:RFGUS
ME:R:S#=01:DCC=004:PH=56333030314643
<COM7: 20170920142004.984 TX>
rfsst 01 1479C25900000000
<COM7: 20170920142004.995 RX>
CR:Ack=0:RFSST
<COM7: 20170920142100.617 TX>
rfemd 01 1
<COM7: 20170920142100.654 RX>
CR:Ack=0:RFEMD
... now starts the interesting part, these 
... are actual measurements,
... payload seems to be at "PH"-tag. 
... They continue until rfemd 01 2 command is issued
ME:R:S#=01:DCC=010:PH=01000042020C0601
ME:R:S#=01:DCC=010:PH=00000042020C0601
ME:R:S#=01:DCC=010:PH=00000042020C0601
ME:R:S#=01:DCC=010:PH=01000042020C0601
<COM7: 20170920142116.922 TX>
rfemd 01 2
<COM7: 20170920142116.930 RX>
CR:Ack=0:RFEMDME:R:S#=01:DCC=010:PH=00000042020C0601

After looking at this, it seems that we need only to issue few commands to get it to register (and wait for a while between commands):

writeToPort("rfsm 1", 2000);
writeToPort("rfdis 1", 3000);
writeToPort("rfebd 01 0", 3000);
writeToPort("rfgsid 01", 2000);
writeToPort("rfgus 01", 2000);
writeToPort("rfemd 01 1", 2000);

Below is writeToPort-function used in above example and also other necessary  functions to get it running.

void writeToPort(string t, int delay=1000)
{
 serialPort1.WriteLine(t);
 System.Threading.Thread.Sleep(delay);
}

private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
 string reply = serialPort1.ReadExisting();
 if (reply.Contains("ME"))
 {
  string value = parseReply(reply);
  if (value != "")
    lblValue.BeginInvoke(new MethodInvoker(() => lblValue.Text = value.ToString()));
 }

}

string parseReply(string input)
{
 string val = "";

 // ME:R:S#=01:DCC=010:PH=00000042020C0601

 if (input.Contains("="))
 {
  string[] linesA = input.Split(':');

  foreach (string lineA in linesA)
  {
   string[] lines = lineA.Split('=');
   if (lines[0].Contains("PH"))
   {
     // payload ?
     try
     {
        string pl = lines[1];
        pl = pl.Replace("ME", "");
        pl = pl.Replace("\r", "");
        string lvalue = pl.Substring(0, 4);
        string msb = lvalue.Substring(2, 1) + lvalue.Substring(3, 1);
        string lsb = lvalue.Substring(0, 1) + lvalue.Substring(1, 1);
        string plusOrMinus = pl.Substring(6, 1);
        string mvOrNot = pl.Substring(pl.Length-1, 1);
        int num = int.Parse(msb + lsb, System.Globalization.NumberStyles.AllowHexSpecifier);
        if (plusOrMinus == "8" || plusOrMinus=="C")
          num = num * -1;

        if (mvOrNot=="1")
        {
          double dval = Convert.ToDouble(num) / 10.0;
          return dval.ToString();
        }
        return num.ToString();
      }
      catch (Exception ex)
      {
          return "";
      }
     }
    }
   }
   return val;
}

As you can see, pretty rudimentary and not at all complete but it get’s it done, I’m able to read Fluke Connect module output to my own software 🙂

I still need to see what kind of coding there is at the position of decimal point for example and see better positive/negative value handling – preferably understand what each byte or bit means.

For now, this simple program gets me where I want, just rudimentary readings from wireless Fluke Connect module to my own C# software. If I ever fully decode what full payload message means, I can write an new blog-post.

For now, I have found out that the first 4 characters contain  measurement value  in hex. This is the same value that is displayed in the screen of module.

I have logged few data-points to help decode this:

# mV positive 546.0 (?)
ME:R:S#=01:DCC=010:PH=54150042020C0601

# mV negative
ME:R:S#=01:DCC=010:PH=531500C2020C0601

#Volts negative -0.758
ME:R:S#=01:DCC=010:PH=F6020086020C0600

# Volts positive 0.758
ME:R:S#=01:DCC=010:PH=F6020006020C0600

# Volts positive 7.53
ME:R:S#=01:DCC=010:PH=F2020004020C8600

# Volts negative -7.53
ME:R:S#=01:DCC=010:PH=F1020084020C8600

# Just a bit over -30V, red lightning led ON
ME:R:S#=01:DCC=010:PH=B90B0084020C8620

# Just a bit under -30V, red lightning led OFF
ME:R:S#=01:DCC=010:PH=B40B0084020C8600

These have all come from Fluke Connect DC voltage module V3001 FC. I will eventually also log what 3000FC Multimeter and 3000TC temperature modules will output. But for now, this should get things going…

If you have any information or suggestions, please feel free to contact me.

Until next post, have fun!

 

It’s official – my Porsche Boxster is road legal ! It’s officially (verified from Trafi) first electric Porsche in Finland 🙂

For celebrating this, here is a short video:

Time flies by. It sure feels like so when looking back to start of my  eCagiva electric motorcycle project. In this post I mirror eCagiva-project to other aspects of our life and surely things have changed a bit since the start of this project.

I started to build eCagiva in 2009. Location was a “bomb-shelter” workshop. It really was an old bomb-shelter! Tight space with a very low ceiling. I was renting it for about 10 years before finally moving to bigger workshop (more on that later). There I had an small lathe (I converted it to CNC), an homebuild CNC-mill and few homebuild 3D printers. But no proper welding or metal working equipment. Still I managed to build few electric motorcycle conversions there. Nice memories on that first workshop 🙂

For about a year eCagiva was equipped with a custom made AC motor and a Sigmadrive AC-controller along with Cedric Lynch BMS. This was equipment it was registered with, got it street legal at 2010. After a while that custom made AC-motor gave smoke out – it overheated badly and stopped working.

This was in the middle of summer driving season. I  decided that next motor will be proven DC and contacted 2009 TTXGP-winning team Agnimotors. I got their factory repaired racing motor Agni 95R quite quickly delivered to me. I also installed Kokam 70 Ah cells, Kelly KDHE-controller and an Elithion BMS. I drove with this combination for few years and it worked nicely. For a while I had also an onboard charger, PowerFinn PAC800 (800W) but broke it after driving in rain (my fault, lack of proper water-protection…).

After hearing about nearby bargain on 7.5 kW, 2.5 ton metal lathe I had to say big YES. So I bought the big lathe even though I didn’t have enough workshop space for it… That was one of those “once in a lifetime” offerings and I really had to yes to that one. This gave an nice excuse to rent a new workshop –  bigger and with higher ceiling. Lathe was easy to move in with standard lifting truck and plenty of room for eCagiva and other projects too. This was also around the time when I quit my day-job and started to work for my own company.

Soon after moving to new workshop eCagiva got an electric friend – a Porche Boxster conversion project started when we found a nice donor-car. eCagiva worked fairly well, minor repairs here and there but mainly ok and all the time drivable.

After spending less than one year in that workshop our landlord offered nearby office/workshop-space for us to rent – more than 2x space of previous workshop for little more rent. So we rented it and got more space for our projects. Soon after that we found another electric car, Elcat van with Lithium batteries. Decided to have it since it’s perfect for testing various components. Elcat has been our daily driver ever since. We also found few electric bicycles.

eCagiva was mostly working fine. Some nuances still

• lack of on-board charger
•  

  too long chains, they kept rattling noise

• wrong location for controller (front tire bumbed to it in hard braking!)

 

In summer of 2014 I found out that one Kokam cell had  discharged to fully empty and had been destroyed by that event. I decided that this was good time to make an major overhaul on the bike.

• replace BMS with our own system
• move motor to better position
• move controller to better position
• install on-board charger
• make a better mounting for battery box

My friend Eero designed an nice 12 cell BMS-node with a CAN-bus and few other bells and whistles. I made an BMS-main unit to control those nodes and handle other things in my conversions. BMS and other components were tested in Elcat and they seemed to work really nicely.

It took a while to get that overhaul to finish – in fact one more workshop change was needed to find time for finishing the overhaul.

In 2015 summer we found an ideal solution – an house with a proper workshop.

After moving in and few months of settling down I decided to bite the bullet and finish the overhaul. Now I had a proper MIG and AC/DC TIG for welding both aluminum and steel so fabrication of parts was much easier than previously. Also I had an small metal mill and large lathe so it was fairly easy to fabricate necessary parts. I installed an water cooled 3kW Eltek Valere charger under the seat and build an water-cooling system for it. Charger is  controller via CAN-bus and I integrated all the control functions to my driving user interface, an IFM IP65 rated color display. After a “few” days worth of work on the bike it was running again. This time better than ever.

So in the summer of 2016 bike was driven more than ever and worked finally like it should. When I look back, it certainly seems that it took few iterations to get it right. Now it’s beginning to feel fairly good. I wonder how the Boxster project will be, do I need to do few iterations on that also …

Still some minor adjustments could be done for the bike – such as making more stable 12V. I think DC/DC is strugling to power everything since it sometimes shuts off. Most likely I’ll add an small 12v lithium-battery in parallel to DC/DC converter for better 12V voltage stability.

Here is an video of the eCagiva as of 2016.

That’s all for now, thanks for reading and have a nice time building your own way forward !

It’s been a long time since last updating this blog.

Quite a bit has happened in the meantime –  we bought an house, workshop has been moved, got a bigger solar panel array etc.

Biggest thing is that finally I have my very own workshop in my yard. Nice big doors so I’m able to move bigger projects in and out easily. Can’t say enough how much this has changed the way I do things – I’m able to visit workshop for just 10 minutes if needed. Previously it was always about 10 kilometers (one-way) trip to workshop. So visits tended to last longer than 10 minutes and had to be “planned” a bit beforehand because of that.

Now, it’s just a matter of walking of about 10 meters from our front door, doing some minor or bigger work and getting back to house when ever it feels like so!

This has been a dream of mine since childhood – to have proper tools and workshop at home 🙂 Finally managed to have it happen – JIIHAA 🙂

Personal projects have flourished – this year I have managed to

1) get water-cooled 3 kW CAN-charger installed to eCagiva e-motorcycle and have eCagiva motor moved about 10 centimeters backwards and controller moved few centimeters downward. This has helped a lot for handling of the bike.

1) convert an 1.2 kW full suspension electric bike to fully working condition. It spins wheel quite nicely but still needs some minor work to be done.

3) have my electric Porsche Boxster conversion finally moving !

Here is the very first driving out of my workshop – I know, hood needs proper cleanup after sitting few years. But still, it’s moving 🙂

It took a lot longer than expected but finally I managed to get it moving. No big battery pack yet, just a small pack in the trunk. Mainly to move it around workshop. Next up front trunk battery box wiring. And all the other little bits and pieces.

 

 

 

I have recently tested whether Raspberry Pi is a good DIY solution for electric car UI computer. It seems to work well – it has been in use for a few days now and it seems to run fairly smoothly. Here is the basic schematic of the system:

So Raspberry Pi is equipped with an CAN-bus shield and an wlan dongle. I compiled a custom kernel that supports both of these devices and wrote a very simple Python script to read values and pass them to web UI. CAN bus has new messages from shunt every 250ms and from BMS every 1 sec so update rate will not be so quick. I’m confident that RPi can easily handle all this. I’m using Arch-Linux as it seems to work quickly and nicely with Pi. I keep my Raspberry PI always powered on as it doesn’t really use much energy (only few watts) and I have about 23kWh battery. Raspberry Pi creates an Ad-Hoc WLAN around the car so I can easily connect to it. I’m most likely going to replace that with a proper WLAN router though (since Ad-Hoc doesn’t seem to support WPA2 encryption which I would very much like to have).

For powering the Pi, I just made an 5v PSU from stock “car usb-power adapter” and enclosed it with a Pi to a plastic box.

Here is a picture of the box:

Not pretty but hey, it’s a 1st prototype 🙂

In the CAN-bus there are 3 devices: 1) Raspberry Pi, 2) Isabelle Huette “intelligent” current-shunt and 3) few of our own BMS-boards. So when everything is up and running, I’ll be able to read and control all these devices from a mobile phone. For now, I’m only testing the system with traction pack current. But as this already works, it should be fairly easy to read and  display all the other important values as well (such as min/max cell voltages and -temperatures etc.). I’m thinking about adding an USB-HDD to RPi because I want an database for storing all that data for later viewing and analysing. And I have read that database writes could quickly render my main SD-card useless so I’m going to keep my MySQL data-partition on separate HDD-drive.

For now, the display only consists one simple gauge (justgage.com) displaying traction pack current but rest of this setup should be fairly simple – just add some more UI-software for other values as well. You can see how my 1st working setup actually works from this small video:

The source code is not yet ready for “prime-time” but eventually this all will most likely be Open Source. For now, this is all I have – I’ll post more when I update the display and get those BMS boards also to display some values on my phone.

We decided to invest in a small solar power plant. We have only 2kW worth of panels but that should be more than enough to cover our daily drivings with Elcat, eCagiva and Porsche.

I bought some wood for mounting the panels. Elcat-EV was handy for towing the woods to our workshop.

After few days of installation and building we had a nice array of 8x250W panels installed.

What remains to be done is connecting the Sunny Boy 3000TL-21 to grid and start using this array. That is planned to happen next week. Also as inverter has a Bluetooth connection, we can make an live tracking of power generation.

We had a need for a small BMS system for FlyNano electric airplane. We didn’t find any existing system that would suit for our needs. So we decided to roll our own system.

Design goals were

• Small weight
• Proven measurement technology
• CAN-bus
• Minimal power draw from cells
• Suitable connectors for 6S and 5S LiPo-packs

Based on these goals we settled on using LTC6803-4 BMS-IC along with Atmega64M1 microprocessor. With these goals in mind Eero Vuorinen designed an PCB and we have build first prototype batch of these boards.

Each board can handle 4-12 cells and has an isolated CAN-interface along with 8 Mbit of eeprom-memory for storing cell-voltages etc. Also power is controlled via isolated DC/DC converter so almost whole board can be powered off when not in use. Here is a picture of almost bare PCB with only LTC and Atmega soldered:

That’s 2-sided PCB with about 150 SMD-components on each side.

Now we have about 5 of these boards up and running with basic software capable of measuring cell voltages and sending them to CAN-bus. First tests have been made to test whether LTC<->ATMEGA SPI bus functions without any level-converter between them and whether it works also in noisy environments. For that we have made an basic test-setup consisting of Dynaload variable 4 kW load, Powerfinn 0-120V charger, an National Instruments USB6251 BNC DAQ card with Measurement Studio along with some custom C# software for making some basic measurements. Here is the current schematic for our bare-bones BMS testing setup:

Temperature measurements are missing from above diagram, those are also planned but not yet implemented. With this setup we are able to test either manual tests or make some more automated tests in the future. For now, we have tested that the SPI bus seems to work with quite big current pulses also.

So far highest peak to peak current values have been about 120A with about 5 kHz frequency and current pulsing between 0 – 120A. We also did about 40A peak-peak with frequencies up to 20 kHz. With this kind of frequencies the A123 M1 test cells seem to warm up very quickly. They might be destroyed if we keep this test going for too long but as this is mainly about wheter or not our new BMS-boards work in noisy bench-environments, it is not so big deal if we destroy a cell or two – provided that we get the results we need to proceed our BMS implementation.

For now, we have 11 pcs PCB’s and parts for 12 boards so we could cover about 132 cells with these boards. But as these are “0-batch” boars there are already some issues to be fixed in “1.0 – batch”.

Here are few shots from latest measurement sessions:

60A peak-to-peak, 1.2 kHz

In the picture above we have a oscilloscope connected to a Fluke i310s current-clamp. We are measuring both peak-to-peak, RMS and frequency of our current spikes. Purpose of this test was to see if SPI communication works in noisy environment too. These kind of load-spikes could generate some noise on our measurement circuits and it would be nice to be able to reproduce some of that actual noisy EV-environment with our bench testing before we install these to any actual vehicle.

BMS-node along with A123M1 cells on left with current clamp connected to scope

Here we have actual measurement setup. Small module of A123 M1 cells on the left along with a BMS node and a current clamp connected to a scope. That massive thing below oscilloscope is Dynaload variable load capable of generating 0-600A / 0-400V / 0-4 kW DC-load up to 20 kHz frequencies. And few important safety issues – cells are on the table that has wheels – just in case it needs to be rolled outside quickly. Testing station is located so that is only about 2-3 meters from the large doors for easy emergency “eject” of the cells under test. Under table there are large cutters capable of cutting easily up to 100 mm2 cable for quick disconnecting the cells. Also safety goggles are needed whenever testing these cells – they are easily capable of making very big sparks if accidentaly short-circuited.

Small program running on Atmel and continously testing SPI-communication between LTC and Atmel

Here is a small software running on Atmel ATMEGA64M1 processor and communicating with a normal laptop with just a RS232 port. It continously scans for commucation errors between LTC and Atmel. So far we have not been able to generate any errors while testing different frequencies and currents up to 120A. That current is quite small for any serious EV-use but as our test cells are just 2.3Ah cells they are already screaming “help” with about 50C discharge spikes hitting on them with about 5 kHz frequency 🙂 I don’t know if anyone has connected a scope along with a current clamp to any EV while driving on highway. It would be interesting to know if high frequency peak-to-peak values are above 120A. We will eventually know this for sure but for now, this is all we needed to test from SPI. Now we have moved on to test a battery with 3 nodes with 5/6/6 cells configuration so total 17 cells on that test. As each node can have up to 12 cells and there can be 16 nodes on same bus with this hardware it totals to 192 cells in the largest possible battery with this system.

It’s been really nice to have few free days off from work and have some easter fun with family. We decided to finish our electric go-kart project that has been waiting for inspiration for many months. Snow is starting to melt and workshop front yard has an asphalt covering already visible – so it’s ready for kids to drive with their car.

Yesterday we got the kart moving by just connecting some 12V UPS batteries with 2S2P configuration directly to motor. Motor is a small motor from Chinice “pit” scooter that I got as a gift from a friend. Scooter was not usable but motor seems to be – it’s underrated and not much torque but just fine for kids go-kart (for now at least). I had to run behind kids while they drove and stop the car if needed since there was no on/off switch and/or speed-pedal but it was fun anyway 🙂 (Btw, it was safe because car moves about walking speed and does not have much torque so they couldn’t move far from me).

Today I milled an spring-loaded on/off speed-pedal from aluminum and connected it to 24V contactor. It made driving much more ejoyable for both kids and parents 🙂 So finally kart is drivable and only major thing left to do is some cleanups on connections and decide if we should keep it with Lead-batteries… Or switch to some more powerful A123’s that I happen to have lying around at workshop… (And more powerful motor etc. etc.)

 

PS. It’s a good thing that my friend has brought his 90 kW+ electric go-kart project to our workshop… So I don’t really have to dream going big with this car. This car can stay as a slow kid-friendly workshop-car and we adults can drive with that 90+ kW go-kart (when it’s finished, that is…)  🙂