[quote author="damon"]It would be really nice to be able to access the vector components with '.' accessors, e.g. V[0] ==> V.x, V[1] ==> V.y, V[2] ==> V.z etc. do make the readability clearer.[/quote] The field addressing has now been implemented in the new version 1.5.2. The new version also includes a bugfix and some more examples. You can get it at http://www.vagrearg.org/content/gcmc.
[quote author="bobb"]Hi Bertho. How is the testing progressing. Is things working as you wanted, or has the project stalled ?[/quote] I did test parts of the power board. However, I've been busy for another job and have been unable to do much work these past few weeks. I can get back to this project in a week or two.
What I know so far: 1) The switcher is too aggressive in the soft-start while unloaded and needs to be tempered quite a bit. The soft-start period needs to be cut down with at least a factor of 10. A change of soft-start capacitor should do the trick. The current situation makes the switcher overshoot the target output voltage before the soft-start period is over and that makes it go in shutdown mode. 2) The loop-gain of the analog regulation is too low (stupid mistake). Simply increasing it can be done, but it needs to have a low-pass filter on it to prevent oscillation of the loop. I was doing loop-calculations when I got too busy with other work. There is some experimentation required to get this just right. 3) The D/A converters work and the reference is now correctly at 3.3V. The low-frequency noise levels that I could measure are quite low and fall significantly below the LSB of the DAC. I have not yet had the pleasure of doing an analysis of the high(er) frequency noise. Those measurements need to wait until I have a proper analog loop-gain so that the actual values become visible.
All in all, a good start, but much work needs yet to be done.
[quote author="damon"]Ok I think I get it. You want to be able to post g-code on the fly, via real-time interpreter (not compiler) to LinuxCNC? I thought the intent was to compile a gcmc file into g-code, then import that g-code in LinuxCNC (or Mach3 or whatever.) However, you want to be able to have a gcmc interpreter running inside LinuxCNC, and control the machine using real-time gcmc-generated g-code rather than g-code directly?[/quote] Nja... you compile gcmc code into g-code. However, you create g-code that interprets the gcmc type-system. The actual paths (moves) are calculated at runtime.
Quote
I guess the only way to do that using some other language would be to open up a sockets connection to LinuxCNC (or whatever messaging protocol it allowed, if any - it seems there is a linuxcncrsh that allows you to talk to LinuxCNC via telnet) and communicate via another process, or even another machine . But I suppose that would not be incorporated into the LinuxCNC GUI.
You can rip out the g-code interpreter in LinuxCNC relatively easily. It is a dynamic object which can be replaced with another,
Quote
I didn't know this. Which code does this?
G38.2 ... G38.5 will probe and save the location in memory locations #5061 through #5069.
[quote author="damon"]But I am still curious, why not implement the meta-language in another, already established language rather than making a new symbolic compiler from scratch? Maybe I'm missing something, ...[/quote] Yes, you are missing something. The established (assembly) language is g-code. The high-level language is gcmc-code. If you compile gcmc constructs into g-code, that is you write a gcmc interpreter in g-code, then you can interact with the CNC-machine at the gcmc level.
For example, g-code allows for measuring of points on the object you are creating. Those measuring points are readable in g-code, but gcmc has currently no way of using them. You need to interpret gcmc-code in g-code to create a list of vectors measured and then calculate on that list.
The current gcmc-backends creates statically compiled paths and the communication is one-way. However, if you allow for interpretation (dynamic compilation), then you can do two-way communication with the CNC-machine at the high-level language. That would effectively mean that you can make g-code completely invisible at the CNC-machine programming level.
It has been suggested to rip out the g-code frontend of linuxCNC and replace it with a gcmc-frontend. That is a lot of work and would only work for linucCNC. However, if gcmc can compile to a dynamic intermediate langage using g-code, then you are not limited to linuxCNC. There are both advantages and drawbacks for any direction of development, and it has not been decided which would be most beneficial.
[quote author="damon"]However, one instance in which the ability to deal with raw G code would be cool is if, for instance, you had a widget designed with CAD, whose tool paths are not easily described using a scripting language (nor would it be good use of time to do so; it is, for instance, quite complex with weird angles in all planes.){snip}[/quote] But, when you have your source in the CAD program, you already can do this quite easily. You can copy your object, rotate and transpose it too in the CAD program before you export. I cannot see why you would want to do that after you lose information due to a compile step. It is always better to do geometrics beforehand.
The really hard part for gcmc is that it must track the absolute position of the tool in order to satisfy the internal (compilation) state. That is why it needs to know where the imported g-code is taking it. Otherwise, subsequent code will be off, position-wise. Tracking only works if you interpret the g-code...
Quote
I'm not quite following the limitation imposed by LinuxCNC and how it fits into the inner workings of gcmc, but I assume there's something going on that I just don't understand.
That is one of historical reason afaik. There has never been a reason either to have "large" g-code programs. It is a real pain to write them anyway, and the reason why I wrote gcmc, to overcome the archaics of g-code.
Quote
I was wondering, however, why not just make a library extension using some other language? For instance, a 'ToolPath' object that handles all the vector primitives and G code functions contained in gcmc (and additionally a G code parser for good measure!) while not having to reinvent the base language and compiler? Just curious if there was some reason I'm not considering.
I think you underestimate the complexity of a g-code interpreter and how many primitives there are. Surely, I could import the linuxCNC g-code interpreter, but I'd rather spend the time creating a symbolic compiler.
[quote author="damon"]Really I'd only like to have the ability to read lines from a file and put them into a string, and then have some some basic string tokenizing ability (there's got to be open source string and/or even regex libraries out there?) and I would write the G-code interpreter in gcmc. It's not a huge deal, since I could always write a "G-code to gcmc vector" script in some other language and just include the vector in the g-code, but it would be cool to do it in gcmc!![/quote] It kinda defeats the point of gcmc. When you have g-code, you have lost the geometric description of your object at the highest math level.
You should look at it this way: 3D math objects (sphere, cube, etc.) ==> abstract vector description (gcmc) ==> path description (g-code). You can say the same for other computer languages: algorithm (pure math) ==> C language (programming implementation) ==> assembly (CPU instructions).
Going a step back is a hard thing to do because you lose (descriptive) information in the compilation processes. Gcmc does not use any calculational capability of g-code because it does not use symbolic compilation (like C to assembly does). The output is purely path-based movement in relative or absolute coordinates.
I have considered symbolic compilation, but that requires a statically typed language and a g-code interpreter that has many more memory locations than 5000 (LinuxCNC has a define that controls this). In principle, you implement a virtual machine in g-code to run compiled intermediate gcmc code. The advantage is that there can be better integration with some machine interactions (reading back values), but it turns out to be quite hard to implement.
[quote author="damon"]It would be really nice to be able to access the vector components with '.' accessors, e.g. V[0] ==> V.x, V[1] ==> V.y, V[2] ==> V.z etc. do make the readability clearer.[/quote] That would be a nice addition. The first 9 indices (0..8) are XYZABCUVW if all 9 axes are enabled. Otherwise only the first 6 are active. I have to take a look how that would affect the parser to make it look "nice"...
[quote author="damon"]Also, any hope of file read/write capability and string (parsing/tokenizing) functions? It would be nice to read a pre-existing G-code program (some tool path output by cam software for instance) and parse it into a vector list, which can then be manipulated (scaled, rotated, repeated in a matrix, etc.) by gcmc.[/quote] That would be a hard thing to do because it requires a full G-code interpreter. That is not part of the goal(s) fot gcmc. G-code is the assembly of the machine and you want gcmc to de-compile the assembly into a high-level program. That is very hard to do.
String tokenizing and such is not a property that I encourage. The language is not a text-handling program, but a math description of a path. I'd like to keep that thought as much as possible.
[quote author="damon"]Also, a few things I noticed: The 'if' statement requires {} around single statement execution blocks, e.g.: {snip}[/quote] That is intentional. The curly braces are mandatory. Mainly to prevent an empty statement (;) causing a lot of headaches.
[quote author="damon"]Also, the compiler doesn't like this:
as it complains that it doesn't do anything (e.g. no assignment.) I'm not sure if the above was intentional, but it would be nice if this worked more like as expected in C.[/quote] If you write this as a single line statement as you do, then yes, the compiler will complain. Gcmc explicitly discourages expressions in non-assignment statements, even though there are function calls in there. What is allowed in C is a guideline, not a template. It is a source of errors to allow expressions as statements that result in an unused value. Better safe than sorry.
Update: The I2C bus is working and devices can be addressed. Not everything is peachy, though...
The LM4040 3.3V reference is mounted mirrored. It is acting like a diode and not as a reference, so I need to reverse mount it. Should be no big deal for testing otherwise, but,... Argh!... ;-). Once I have the reference working I can start on putting some real juice on the board.
I2C devices: - DAC voltage - working - DAC current - working - ADC voltage/current - getting data, surely the wrong kind; only one channel data makes sense - ADC temp sensors and various measuring points - only channel 0 gives data. Need to read the datasheet a bit more, I guess - Digital IO - working (can flip the relays)
The ADCs are quite annoying. I really need to read the datasheets to see what I missed. You know how that goes... How little must I do to get the most. Apparently, the ADCs are ones that cannot suffice with too little effort.
For the DACs, I need to find a proper micro-volt meter to get the real voltages. The LSB is ~50 uV and that puts your simple multimeter into the "not sufficient" category.
Note to future self: Put lots and lots of measuring points on the board! It is a pain when no pads are available to measure on the power board. Putting a multimeter on an SOIC can work, but it gets really awkward when the package is MSOP/TSSOP. Also, a probe on a resistor is not easy.
[quote author="aramosfet"]Can anyone explain what are the advantages/disadvantages of running switching converter where the output voltage is ~90% of input voltage?[/quote] It is a disadvantage because the switch is in the "on" state a lot of the time. That means that the dissipation of the switch is a major concern and source for losses. The second disadvantage is that your region of control is smaller. The startup takes longer and you risk controller shutdown if you cannot come up to the target voltage (or current with current feedback) withing a reasonable time, but that depends on the controller you use.
You can use something like NCP3170 and use a current feedback instead of a voltage feedback using a current-sense resistor in the load line to ground. The important parameter is to find a buck converter that has a low feedback voltage on the error amplifier to minimize the loss in the current sense resistor for the feedback. With 0.8V of the NCP3170 at 0.6A you'd dissipate ~0.5W there.
A simple alternative is to add a small 1:2 to 1:4 opamp amplifier so you can reduce the dissipation in the sense resistor. That means that a lot of controllers become available (most have a 1.25V or 1.275V feedback line). However, such amplifier needs to be of relatively good bandwidth and good phase linearity and stability for the control range.
Did some test-bed assembling today and did a dry-test of the power board.
The good news... the power board did not blow up ;-)
The aux PSU for +/-12V analog and the 5V logic supply switcher is working as it should. The power board is able to supply the control board as far as I can see. Haven't done any in-depth testing, but it looks good. The main low voltage AC inlet is also functional and the default of the power switcher is correctly off. The DC voltage after the rectifier was tested to 42V DC and no sparks or smoke were detected.
With the preliminary tests complete, I have now a small test-bed to continue working. The setup has the control board with LCD, 2 encoders (+ push switch) and 3 LEDs. All is powered from the power board aux supply. The main power has a separate power cord on the transformer so I can control settings before actually doing any load tests and destroy everything in the process..
Finally, the LCD is working with some text displaying.
I have to admit, the LCD is hard to interface in software. Not that the communication is hard to do, but the pixel-buffer orientation is a real pain to handle. A few cents of extra silicon hardware in the controller would have saved many hours for many programmers.
The backlight is hardware-PWM'ed (at ~730Hz) using a timer and with quadratic intensity correction (14 -> 8 bit). The red LED is not as high intensity as the green and blue ones. I have to hack the series resistors a bit to make them a better match. It seems that the red has 100 Ohm in series, while green and blue have a 0 Ohm mounted (measured 0.5 Ohm).
[attachment=0] The image looks a bit shaky because the text is actually moving from left to right and the LCD crystals are really slow. The diagonal line (which is sharp) was used to debug the bit/byte ordering of the pixel-buffer translation routine. The text font is a manually bit-mapped version of Liberation-Sans-Narrow-Bold of 36px (bbox 18x29 for numbers). Only few characters have been converted (0123456789.AV) because it will only be used for voltage/current display.
At least my serial routines on the primary port worked without complications or rewrites (copied from another project), and printf debugging was really helpful.
The compiler issue is still around for the new version, so I am using the old one. I still have no clue as why the error occurs. The assembly looks fine to me. That'll have to wait until I get time to create the proper jtag config files (and test the jtag interface), which is also a lot of work. Oh well, small steps ;-)
Next up are the I2C interface and adding the rotary encoders for easy and quick interfacing while testing. Getting closer to the point where I can start interfacing the power board.
[quote author="prasimix"]I have a question about rectifier diodes on the input. Did you try to put it under planned load (3A) and see what is a temperature of the PCB around them? What type of diode is VP10P10? Farnell, Digikey and Mouser search return nothing.[/quote] There is a typo in the model number; it is V10P10. See: http://dk.mouser.com/Search/Refine.aspx ... -V10P10HM3
I have not yet tried the power board. The rectifier diodes are geared towards high power at a total loss of under 2.5W and the PCB should get rid of quite a bit of heat. My estimate in the design was under 50 degrees above ambient at full load for prolonged time. But, it needs te be tested.
I have been battling the compiler this week and I still have to word out an issue. I tried using clang, but it resulted in exactly the same error as with gcc 4.8.1. So, either it is an assembler issue (both use the same assembler) or I have an issue in the code yet to be discovered. The main problem here is that it occurs before main() is called and that makes debugging more of a challenge.
Ha! not my fault... Switching from gcc 4.8.1 to an older 4.7.3 fixed the problems. Apparently, there is too much code movement/reordering in 4.8, which makes the code unreliable. Haven't tracked the actual culprit, but for now I do not care. There is still some volatile ignorance in there, which forces me to insert NOPs and DSB barriers.
The LCD backlight is now flashing in rainbow colors and the serial port spits out my debugging. Next up is to get something displayed on the LCD and initialize the I2C interface. Progress is slow, but at least now I can code and debug.
I managed to get the microcontroller programmed after hacking it into lpc21isp and adding the new lpc11[ue]6x chip(s).
After a while I got blinky to work, sort of, but there is an error somewhere in the system initialization that causes the ARM core to go into a hardfault after/while returning from the system init function and before calling main. My hardfault handler is to blink the display red (hardcoded) and it is quite a bit of red I see at the moment. I guess I'm trashing the stack.
The lpc11e67, which I use, is new and that means that all docs are sparse (some inconsistent) and the PLL setup is not yet working as it should. Calling the ROM API to do so also gives me trouble. I have yet to hook up JTAG, but the prospect of creating a new profile to do so has scared me off until now (well, significantly discouraged).
Open Source Hardware