I've been writing the cut paths directly by spreadsheet formatting basically. Any slicing program would create g-code that doesn't line up with the firmware on the board once I finished stripping it down. Snapshot of one cut path file: This makes a very similar part to the video just the center is a circle instead. Like you saw in the video, Pronterface is the driving program and that's on Ubby ItsDrone - CNC Routers, Mills, and Hybrid RepRapping
It isn't that far from possible. I have already built a crude table to create some parts for another project that I didn't want to make with hand tools. The basics of the design uses a Gen7 1.4. One of the Fets drives a 12V relay that triggers the plasma gun via seperate pcb board. The firmware used is TeaCup, major modifications thought. For the crude build it's only 2 axis build to make itby ItsDrone - CNC Routers, Mills, and Hybrid RepRapping
Good points. This is how I plan to work it out. Both are master and both are slave. The display board (8u2) interfaces the user's inputs either from the keypad/display or via usb connection. This board passes a request for bus control and then sends the info directly to the 644. (no delay commands, basic communication). When it comes to G* codes it will request an address from the 644 and thenby ItsDrone - Next Wave Electronics Working Group
Thanks for all the feedback guys. I've been looking into a dual board setup and this exact thing might cause an issue. Timing will be done with a 644* and display/sd card/usb will be driven with an 8u2. The idea was to link them via 3 wire spi and buffer between them with 512kb sram. All of which clock differently but the main concern would be the link between them. 644 at 20 mhz and 8u2 at 16by ItsDrone - Next Wave Electronics Working Group
I have been looking over the Gen 7 1.4.1 schematic/parts list and noticed that the capacitors used for the crystal don't match what the crystal says should be used. The crystal is listed as 18pF load and the parts list has 22pF instead. Is there a reason the 22pF was chosen over 18pF? It seems like the capacitor might have been an after thought change. They don't fit properly in the spacing onby ItsDrone - Next Wave Electronics Working Group
It looks like I was jumping a head of myself. The spikes for when the queue completely emptied out was due to the rehoming commands waiting for the queue to empty out before it would continue. I'm not sure if that is a reason for flaws or not major enough to cause an issue. If someone has a gcode file that has caused issues with slowing down while running Teacup please let me know. I'd like toby ItsDrone - Firmware - mainstream and related support
Here is the method I followed for this: new pull: git clone teacup_master cd teacup_master git pull origin master ln config.gen7-v1.7.h config.h ln ThermisterTable.double.h ThermisterTable.h adjust per previous post. make gedit mendel.lst mendel.lst is being processed from mendel.elf. I sure hope by then it would be considered optimized. A side note: I cleared out all patches and startedby ItsDrone - Firmware - mainstream and related support
I would agree with you but the compiled code doesn't match up to optimizing it out. The code snippet in question: case 'G': next_target.G = read_digit.mantissa; #ifdef DEBUG if (DEBUG_ECHO && (debug_flags & DEBUG_ECHO)) serwrite_uint8(next_target.G); #endif break; case 'M': next_target.M = read_digit.mantissa; #ifdef DEBUG if (DEby ItsDrone - Firmware - mainstream and related support
Traumflug, I did a little more digging and a little confirmation on how a snippet was ordered and came up with this change for a little more speed. Instead of testing for every possible letter and then processing the digits, I've changed it around so that it processes the digits first and the letters second. This makes it not have to go through 110 byte's of tests, roughly 55 cpu cycles beforeby ItsDrone - Firmware - mainstream and related support
That works with the same result. The main reason I had it set as a user define was due to it using more flash space and give the user the option to chose. 9 instances of enqueue in the complete code. Done the original way it consumes 8 bytes per reference and 10 bytes for the function. With the SPEED/inline method 12 bytes per reference. original: 82 bytes inline: 108 bytes I guess it isn'tby ItsDrone - Firmware - mainstream and related support
I have been looking though teacup firmware and I believe I found a possible resolution to the speed calculation overflow issue. There is also a minor change to reduce a few cpu cycles per G# line. Diff list The background in these ideas: Calculation starts with the upper 16 bits and then process the lower 16 bits. This doesn't return the exact same result as the original would have if it wasby ItsDrone - Firmware - mainstream and related support