Compiling working code?

[pcats]

Do any of the branches produce code that works? I can compile all the branches except master and edge correctly (using mint 16 linux), but the binaries they produce all have the same problem, which is that the stepper motors then run in little random lumps, as if there was something else taking most of the processing power.

The edge and master branches don't compile, the makefiles appear to be badly broken. With some fiddling around I managed to produce a hybrid of the alden branch and the master branch, a horribly ugly thing to do, which involved moving the 'platform' and 'motate' directories from alden to master, along with the makefile and also editing the hardware.h file slightly. It builds, then produced exactly the same result, ie little random lumps of stepping.

I'd like to find the working source to whatever produced the http://synthetos.github.io/g2/binaries/TinyG2_Due_rob_usbtest.bin binary, which does at least work except for the homing switch issue, so I could hard code my machine settings into it.

[krasin]

Hi @pcats,

g2 repo is currently missing the continuous build (TinyG repo has gotten it recently: https://github.com/synthetos/TinyG/tree/edge), so the build failures are not surprising.

I will spend some time this weekend to add a Travis CI config and fix the build. No promises, since I just recenly started with TinyG codebase and have never even looked into G2 code (although, I expect it to be similar)

[krasin]

@pcats I have successfully compiled the code from alden branch. Also, I have sent a CL that adds Travis CI config to the repository: https://github.com/synthetos/g2/pull/12

Here is the Travis CI logs which demonstrate the successful build: https://travis-ci.org/krasin/g2/builds/26464826

I would recommend to build the code from alden branch (without merging it with master) and try to use it (no guarantees, I don't know what I am talking about)

[pcats]

Thanks for that, but I'm not sure it will help my specific problem. I can already compile the alden branch, but the binary it produces doesn't work correctly. The rob branch produces the same issue, although it builds fine as well.

The built binary I have, which does work, doesn't seem to have any available source.

The master and edge branches won't build at all.

I'll try your version to see what happens, I suppose it's possible that some weird compiler switch has caused a problem.

[giseburt]

Hello,

G2 is currently in very active and rapid development. The only branch that will be guaranteed to compile at any time will be master.

However, Master is currently too old. Once we have a few things buttoned up, we will merge into master and close this issue (and a few others).

-Rob

On Saturday, May 31, 2014, Ivan Krasin notifications@github.com wrote:

@pcats https://github.com/pcats I have successfully compiled the code from alden branch. Also, I have sent a CL that adds Travis CI config to the repository: #12 https://github.com/synthetos/g2/pull/12

Here is the Travis CI logs which demonstrate the successful build: https://travis-ci.org/krasin/g2/builds/26464826

I would recommend to build the code from alden branch (without merging it with master) and try to use it (no guarantees, I don't know what I am talking about)

— Reply to this email directly or view it on GitHub https://github.com/synthetos/g2/issues/11#issuecomment-44755122.

[pcats]

Thanks for the update. Is there even a rough idea of a timescale for this? Not wanting to push but I really want to use it :)

[giseburt]

And we really want you (and others) to use it! ;-)

We won't merge it to master until we feel our changes are stable. However, we may do an intermediate merge branch for testing. I'd like to have that within a week, personally.

We will update this issue if we do an intermediate merge branch as well.

-Rob

On Saturday, May 31, 2014, pcats notifications@github.com wrote:

Thanks for the update. Is there even a rough idea of a timescale for this? Not wanting to push but I really want to use it :)

— Reply to this email directly or view it on GitHub https://github.com/synthetos/g2/issues/11#issuecomment-44755694.

[pcats]

Thanks. The version I have running (25.01) aside from the homing switch issue, seems to work very well. I'm just in the process of mounting the laser tube and power supply in my new machine, I hope to have it making smoke by Monday.

If everything works as well as I hope I'll probably upgrade the smaller one I have to the same electronics set. It's certainly much better than the severely hacked reprap electronics and code I currently use with it.

[pcats]

I'm now able to compile the edge branch, but it is producing the same result as the other ones. The stepper motors run in short bursts of movement, with pauses of a significant fraction of a second between them. It's entirely possible I'm doing something wrong, but I'm not sure what.

My hardware is a stock Arduinio Due board, with a stepper driver from ASL which uses four stepstick modules. I've modified it for 3.3v operation. It works perfectly with the pre-compiled binaries I referenced above, but the current Rob, Alden, and edge branches all do this odd movement effect.

They also crash occasionally, but that appears to be normal ;)

I've also noticed that the binary files produced from these branches are considerably smaller than the pre-compiled one. Whether that means anything important I don't know.

Can anyone give me any suggestions? Or is the current code simply not usable yet?

[krasin]

@pcats I think I am having the same issue as you.

Today, I have flashed TinyG built from edge branch and it does not appear to be working. In particular, when I plug my Arduino Due into the "Native USB" port, the host does not see any new USB devices. This is a good indication that firmware has crashed.

My current guess about the cause is these warnings:

\033[1mLinking bin/gShield/gShield_flash.elf \033[0m
\033[1mUsing linker script: /home/krasin/src/github.com/krasin/g2/TinyG2/platform/atmel_sam/gcc_flash.ld \033[0m
build/gShield/flash/cmsis_sam.a(startup_sam3xa.o):(.vectors+0x64): warning: undefined reference to `SMC_Handler'
build/gShield/flash/cmsis_sam.a(startup_sam3xa.o):(.vectors+0x90): warning: undefined reference to `USART3_Handler'
build/gShield/flash/cmsis_sam.a(startup_sam3xa.o):(.vectors+0xe8): warning: undefined reference to `EMAC_Handler'

[krasin]

Indeed, it does not look good, since the target elf file has 3 undefined symbols. This will likely cause the code to jump into the zero address when tried to call one of these functions.

$ nm bin/gShield/gShield_flash.elf | grep 'U '
         U EMAC_Handler
         U SMC_Handler
         U USART3_Handler

[giseburt]

This symbols never get used. They're interrupts for peripherals that are never turned on.

Can you provide more info on the OS you're using? If it's windows, which version, and have you installed the Inf file?

What program(s) are you using to talk to the due?

Also, we've been beefing up the wiki (way over due), maybe something in there can help: https://github.com/synthetos/g2/wiki/Getting-Started-with-G2

-Rob

On Saturday, June 14, 2014, Ivan Krasin notifications@github.com wrote:

Indeed, it does not look good, since the target elf file has 3 undefined symbols. This will likely cause the code to jump into the zero address when tried to call one of these functions.

$ nm bin/gShield/gShield_flash.elf | grep 'U ' U EMAC_Handler U SMC_Handler U USART3_Handler

— Reply to this email directly or view it on GitHub https://github.com/synthetos/g2/issues/11#issuecomment-46103399.

[krasin]

Hi Rob,

I am on Debian unstable. I build with make: https://github.com/synthetos/g2/wiki/Linux-and-OS-X-(using-the-command-line)

[giseburt]

Excellent, Ivan. Thank you.

Is G2 showing up in lsusb?

-Rob

On Saturday, June 14, 2014, Ivan Krasin notifications@github.com wrote:

Hi Rob,

I am on Debian unstable. I build with make: https://github.com/synthetos/g2/wiki/Linux-and-OS-X-(using-the-command-line)

— Reply to this email directly or view it on GitHub https://github.com/synthetos/g2/issues/11#issuecomment-46103698.

[krasin]

Nope. dmesg also does not see anything.

I have verified that if I upload a serial example from Arduino, it is showing up. So, it's not related to the system or the particular Due board.

[krasin]

Actually, I might already found the issue: it seems that Makefile is missing some source files (comparing to XCode project).

For example, to have these symbols defined, I had to add CMSIS/src/startup_sam3xa.c and CMSIS/src/system_sam3xa.c for C_SOURCES.

[krasin]

end of day update: I tried to build on Mac with XCode, but launchpad.net is down right now, so it's a bit hard to get the toolchain. Lame. :(

Will try tomorrow.

[giseburt]

Assuming you have the same tool chain version, you should get the same results. Xcode just calls make.

How are you programming the board?

Since you have access to a Mac, does it see the G2/Due, if just in the USB list?

-Rob

On Saturday, June 14, 2014, Ivan Krasin notifications@github.com wrote:

end of day update: I tried to build on Mac with XCode, but launchpad.net is down right now, so it's a bit hard to get the toolchain. Lame. :(

Will try tomorrow.

— Reply to this email directly or view it on GitHub https://github.com/synthetos/g2/issues/11#issuecomment-46106544.

[krasin]

I program like this: https://github.com/synthetos/g2/wiki/Flashing-G2-with-Linux

And no, it does not see G2/Due if TinyG2.hex is flashed (it sees the USB device, if a serial example is flashed).

[giseburt]

If you hold erase while hitting reset, forcing it into the "boot loader," does it show up in the list when connected to the "native port?"

The bootloader is a ROM program that also shows up as a virtual serial port, and it showing up will eliminate hardware issues.

-Rob

On Saturday, June 14, 2014, Ivan Krasin notifications@github.com wrote:

I program like this: https://github.com/synthetos/g2/wiki/Flashing-G2-with-Linux

And no, it does not see G2/Due if TinyG2.hex is flashed (it sees the USB devices, if a serial example if flash).

— Reply to this email directly or view it on GitHub https://github.com/synthetos/g2/issues/11#issuecomment-46106635.

[krasin]

Yep. dmesg:

[19979.434753] usb 1-2: new high-speed USB device number 9 using xhci_hcd
[19979.451201] usb 1-2: New USB device found, idVendor=03eb, idProduct=6124
[19979.451207] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[19979.451599] cdc_acm 1-2:1.0: This device cannot do calls on its own. It is not a modem.
[19979.451669] cdc_acm 1-2:1.0: ttyACM0: USB ACM device

lsusb:

Bus 001 Device 009: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader

[krasin]

Do you have TinyG2.hex built from the edge HEAD that works? If yes, please, share it. I will flash and check if it works on my Due.

[giseburt]

I will verify as soon as I'm back at my computer.

In the mean time, could you build the latest commit of the Rob branch? Do NOT use it for motion right now. I've been experimenting in there and it's likely unstable, but it know that the USB is stable there.

-Rob

On Saturday, June 14, 2014, Ivan Krasin notifications@github.com wrote:

Do you have TinyG2.hex build from edge HEAD that works? If yes, please, share it. I will flash and check if it works on my Due.

— Reply to this email directly or view it on GitHub https://github.com/synthetos/g2/issues/11#issuecomment-46106766.

[krasin]

Will do.

[krasin]

No dice.

But I have discovered -i option for bossac and here is the info about my Due:

$ bossac  --port=ttyACM0  -U true -e -w -v -i -R TinyG2.hex                              
Erase flash
Write 332332 bytes to flash
[==============================] 100% (1299/1299 pages)
Verify 332332 bytes of flash
[==============================] 100% (1299/1299 pages)
Verify successful
Device       : ATSAM3X8
Chip ID      : 285e0a60
Version      : v1.1 Dec 15 2010 19:25:04
Address      : 524288
Pages        : 2048
Page Size    : 256 bytes
Total Size   : 512KB
Planes       : 2
Lock Regions : 32
Locked       : none
Security     : false
Boot Flash   : true
CPU reset.

I am a bit confused by the version number (2010? really?).

[krasin]

I am an idiot. The following works:

bossac  --port=ttyACM0  -U true -e -w -v -i -R ./bin/gShield/gShield_flash.bin

My mistake was to flash TinyG2.hex, while it should be gShield_flash.bin

[krasin]

I successfully connected via usb:

$
[fb]  firmware build             40.01
[fv]  firmware version            0.80
[hp]  hardware platform           3.00
[hv]  hardware version            0.00

I will update Linux build and flash instructions.

[giseburt]

Which branch is that code from?

Good find, btw. That's an easy thing to get wrong and I didn't put it in my instructions either.

Thank you for sticking with this.

-Rob

On Sunday, June 15, 2014, Ivan Krasin notifications@github.com wrote:

I successfully connected via usb:

$ [fb] firmware build 40.01 [fv] firmware version 0.80 [hp] hardware platform 3.00 [hv] hardware version 0.00

I will update Linux build and flash instructions.

— Reply to this email directly or view it on GitHub https://github.com/synthetos/g2/issues/11#issuecomment-46107074.

[krasin]

That's from rob branch. I will check edge as well, but I don't expect real surprises.

[krasin]

Oh! Loook, MAGIC!!

$ make clean
$ make
...
$ ls -l ./bin/gShield/gShield_flash.bin
-rwxr-xr-x 1 krasin krasin 117704 Jun 14 22:14 ./bin/gShield/gShield_flash.bin

And now with -j4:

$ make clean
$ make -j4
...
$ ls -l ./bin/gShield/gShield_flash.bin
-rwxr-xr-x 1 krasin krasin 30608 Jun 14 22:15 ./bin/gShield/gShield_flash.bin

In fact, with -j4, the size is different with each invocation!

-rwxr-xr-x 1 krasin krasin 12816 Jun 14 22:16 ./bin/gShield/gShield_flash.bin

Of course, there's a lot of linker warnings, but since Makefile does not have -Werror enabled, it pretends that it's an OK build.

@pcats did you use -j option when building the image? That would explain your report:

I've also noticed that the binary files produced from these branches are considerably smaller than the pre-compiled one.

[giseburt]

Yes, another thing for the wiki, I guess. The linker phase has issues with -jX, and I haven't had time to trace down why.

Does edge work fine without it, and programming the bin?

-Rob

On Sunday, June 15, 2014, Ivan Krasin notifications@github.com wrote:

Oh! Loook, MAGIC!!

$ make clean $ make ... $ ls -l ./bin/gShield/gShield_flash.bin -rwxr-xr-x 1 krasin krasin 117704 Jun 14 22:14 ./bin/gShield/gShield_flash.bin

And now with -j4:

$ make clean $ make -j4 ... $ ls -l ./bin/gShield/gShield_flash.bin -rwxr-xr-x 1 krasin krasin 30608 Jun 14 22:15 ./bin/gShield/gShield_flash.bin

In fact, with -j4, the size is different with each invocation!

-rwxr-xr-x 1 krasin krasin 12816 Jun 14 22:16 ./bin/gShield/gShield_flash.bin

Of course, there's a lot of linker warnings, but since Makefile does not have -Werror enabled, it pretends that it's an OK build.

@pcats https://github.com/pcats did you use -j option when building the image? That would explain your report:

I've also noticed that the binary files produced from these branches are considerably smaller than the pre-compiled one.

— Reply to this email directly or view it on GitHub https://github.com/synthetos/g2/issues/11#issuecomment-46107269.

[krasin]

I disagree that it's a documentation issue.

1. Makefile should be compatible with -j option, as nearly every other Makefile in the world does.
2. -Werror option should be enabled to stop pretending that build succeeded, when it's not.
3. Travis CI should build with and without -j, and compare the results, to prevent a regression in the future.

And yes, edge branch can be built and flashed successfully:

$
[fb]  firmware build             37.03
[fv]  firmware version            0.80
[hp]  hardware platform           3.00
[hv]  hardware version            0.00
tinyg [mm] ok> 

[krasin]

Also, should we delete TinyG2.hex target? What is it for?

[krasin]

If there's a general agreement on pp. 1, 2, 3 above, I can work on the fix tomorrow.

[giseburt]

I agree. It’s not a documentation issue. It is indeed a bug.

I was simply saying that on the scale of priorities it’s a minor bug that doesn’t effect final functionality, and until it is fixed it should be documented that it should be avoided.

Also, should we delete TinyG2.hex target? What is it for?

The hex file, with that name and in that place, was simply to placate Atmel Studio, even though it’s calling the Makefile. If a file doesn’t end up there, it considers the build a fail. It’s also the file it will upload automatically before debugging.

It can be made optional and the AS project updated to explicitly build it.

If there's a general agreement on pp. 1, 2, 3 above, I can work on the fix tomorrow.

I agree with those, and would appreciate your efforts greatly!

Side note: I’d have to double check but I don’t think that we want CMSIS/src/startup_sam3xa.c and CMSIS/src/system_sam3xa.c in the build. They will likely conflict with $(CMSIS_ROOT)/Device/ATMEL/$(SERIES)/source/system_sam3xa.c, $(CMSIS_ROOT)/Device/ATMEL/$(SERIES)/source/gcc/startup_sam3xa.c, and platform/atmel_sam/cortex_handlers.c, which are the ones being used. Instead, the correct fix would be to see why those stubs in platform/atmel_sam/cortex_handlers.c aren’t being used. (#include “sam3xa.h” to the top should work, but needs testing.)

Again, Ivan, thank you for working on this! It’s very much appreciated.

-Rob

On Jun 15, 2014, at 12:31 AM, Ivan Krasin notifications@github.com wrote:

I disagree that it's a documentation issue.

Makefile should be compatible with -j option. -Werror option should be enabled to stop pretending that build succeeded, when it's not. Travis CI should build with and without -j to prevent a regression in the future. And yes, edge branch can be built and flashed successfully:

$ [fb] firmware build 37.03 [fv] firmware version 0.80 [hp] hardware platform 3.00 [hv] hardware version 0.00 tinyg [mm] ok> — Reply to this email directly or view it on GitHub.

[krasin]

I have filed #14 and #15.

@pcats can you please try building from edge or rob branch, using these instructions: Compiling G2 on Linux and OS X (using the command line) Flashing G2 with Linux

Please, let us know if your issue persists.

[pcats]

OK, I am getting considerably closer to being happy. Which is nice.

The problem I was having with compiling the edge branch seems to have gone away with the modifications last weekend. I was indeed doing a make clean ; make without the -j option, which produced code that would flash and sort of work. The big problem I was having was lumpy, jumpy operation, which persisted across the alden, rob, and now the edge branches, but was not present in the precompiled binary.

I finally worked out what the issue was with that, which was primarily a hardware one, and fairly obvious when I experimented a bit, not to mention simple to fix. Basically, it was noise on the limit switch inputs! The cable runs are fairly long, since the platform is large, and if the limit switches were plugged in it did this weird behaviour. Unplugging them all made it go away.

I recompiled the code with the switches set to NC rather than the default NO, having rewired the switches appropriately, which made no difference. What fixed it was a 4.7uF capacitor across the switch inputs to filter out the noise. It now runs much more smoothly and homes correctly, so indeed happy happy joy joy.

There is one minor problemette left, which is that the motion still isn't as smooth as the previous, older, binary. When you do a fairly slow traverse on either axis, one it goes past approximately 100mm travel, you can hear the stepper motors faltering very slightly, as if the steps weren't evenly spaced. This behaviour is completely reproduceable, at the same place every time. It's not a mechanical problem, because (a) the other binary doesn't do it, and (b) if you rezero the mechanics to a new position it does the same thing at the same relative offset from that new position. If I unplug the switches the behaviour is the same so it seems to be unrelated directly to the previous problem.

But, that said, it's a lot more plausible now than it was. I have hopes it can now actually be used and tested as a cutter, which I'm rather pleased about.

For the sake of reference my build environment is Mint 16 32 bit running under Virtualbox on Windows 7 Ultimate. I flash the Due using bossac.exe under windows from a script. All that seems to work.

The main problem left is the consistently unreliable enumeration of the Due serial port under windows, as it requires the board to be manually reset after the USB cable is connected more or less every time, or it doesn't find it as a tinyg2 board.

Addendum:

The homing operation now works perfectly, but it throws an error in the form of "######## LOADER - SEGMENT NOT READY" immediately after issuing the G28.2 command, and after it completes. As it seems to work even so I'm not sure what it's on about.