If there is an analog input, you can always connect an DAC 's output to the ADC and as long as resolution is good enough and signal to noise ratio ok and speed not to fast... In the end, you have to bring wires to terminals, and that will be the most expensive part of the game. ;-) The gui to me actually is out of sight. I focus on motion control. To create the optimal axe. And combine axes to whatever virtual axe. The first step I hope to reach: implement the idea, that you can not be in a place without having a speed. Standstill means: speed == 0. So your state at time 0 is position x0 and speed v0, your target is to be at time 1 at position x1 having speed v1 you have to accelerate and so to apply a certain torque. If your target is far away, you will find time to measure during travel position and speed and update your control signal to, in the end, run the optimal path. So you see: in a first step you have a distant target, and you steer to meet this target. Next level your distant target gives you a ramp and you control to follow the ramp by seeing a deviation, identifying the point where the ramp can be reached, so define a more local target etc...
Now the GUI: I am on the way to use Qt. But the goal is to have a (mulit²) propeller based system that can run stand alone. And I have no doubt, P2 will be available the moment I need it.
The reason I replied to that point was that in two stop separate posts you appeared to say that you doubted it was possible. I made no claim as to which method would be better. I claimed nothing more than since everyone else did it in one thread we could if it made sense to do so.
The suggestion that implementing tinyg's movement algorithm was going backwards because the firmware don't fully support 3D printing I don't even understand. I promise I'm not being intentionally obtuse (it is 110% natural). The only way I understand that to make any sense is if you're suggesting we don't look at bringing forward better algorithms because nobody has done it before us.
On reading your posts for a long time that doesn't fit with the idbruce I know.
The reason I replied to that point was that in two stop separate posts you appeared to say that you doubted it was possible. I made no claim as to which method would be better. I claimed nothing more than since everyone else did it in one thread we could if it made sense to do so.
And they may be right and I possibly could save some cog usage. At this point, I am just approaching it from the best way I know how, and what makes the most sense to me at the time. I have a pretty strict policy that I do not use code that I cannot read or understand. Since I have not learned PASM yet, that kind of rules that option out for me. To make it work well within the confines of SPIN, I believe 4 seperate cogs is the way to go.
The suggestion that implementing tinyg's movement algorithm was going backwards because the firmware don't fully support 3D printing I don't even understand. I promise I'm not being intentionally obtuse (it is 110% natural). The only way I understand that to make any sense is if you're suggesting we don't look at bringing forward better algorithms because nobody has done it before us.
On reading your posts for a long time that doesn't fit with the idbruce I know.
I apologize red.... I believe better algorithms are very important.... And I certainly do not know it all, especially pertaining to 3D printing. However from what I understand, the slicer needs to be able to understand the algorithms utilized, to provide appropriate g-code. I code be wrong.
As a general rule as long as you're not using software specific to a specific firmware (eg, makerbot) most/all of the open source slicing tools can create g-code compatible with all of the open source firmwares.
I've run sprinter, marlin and one other which escapes me and used slic3r, cura and a couple of other slicing toolchains over the years and never had an unsupported g-code issue.
Admittedly, I've not been active for 7 months or so so if that changed recently I'm unaware.
Support for arc primitives for example are considered expansions from the baseline g-code for examples but they're not generated explicitly unless to enable them.
In general you're on pretty safe ground. Everyone tries really hard to maintain backwards compatibility.
Get working with the basics them worry about the more advanced options.
If you need help with toolchain support for slic3r et al I can help with that too.
.........To make it work well within the confines of SPIN, I believe 4 seperate cogs is the way to go.
Bruce,
I believe that "to make it work well" in spin will be difficult. Spin is simply too slow to get performance at the "well" level. And having each axis in its own cog adds serious timing issues among the 4 axes. But also, to attempt 4 axes in a single cog using spin, I believe is futile, at least for a real working system. I believe for anything that can be described to work "well", you will need to use assembler.
The Gecko G251X is no couch potato. Utilizing counters, a ramp and step rate can be produced that the drive cannot keep up with. It has always been my intention, to use 4 counters in 4 seperate cogs. However I do not have it all figured out. I may have to resort to PASM in the long run.
EDIT: Or should I say that the motor and driver do not work above a certain frequency produced by a counter.
As I see it, there are 14 files of the utmost importance, when going the route that I suggest. 13 of these files would be ported to the PC serial software and 1 file would be ported to the Propeller. Here is a breakdown of the files that I deem necessary, for the route I suggest:
Over the years, I have developed my own style of programming. I can't speak for others, but for me, when attempting to follow somone elses code, especially if it is difficult to understand, it usually helps me to get a better grasp, by editing the code and putting it into my style of programming. This ususually consists of rearranging the layout of the document, such as the amount indentation, line breaks, line spacing, parameter spacing, bracket placement, how and where comments are placed, etc.... In no way am I trying to say that the Teacup software is unreadable, I am just saying that it will be much easier for me to read and understand, if I adjust the layout to meet my style of programming. Before altering the content of these files, my first goal will be to alter the layout. This is not going to be a head over heels approach, but more of a as time permits approach, because I have plenty of other things to keep me busy. As an added benefit of editing the layout, you basically read and move every line of code, so you become very knowledgeable of where various sections are located.
After altering the layout of these files, I will then begin to change all the data types to match the definitions as established by Visual Studios C++. I believe when I get to this point, I will have a very thorough understanding of the software, and can make various other changes that I may deem necessary. Additionally at this point, I believe they will be some very nice files to have in my possesion, and should be easily adaptable to other files that I already have.
To those folks who rebuked my idea of using four seperate counters, in rebuttal I offer commentary from dda.c of the Teacup firmware:
//How is this ACCELERATION TEMPORAL expected to work? All axes work independently of each other,
//as if they were on four different, synchronized timers. As we have not enough suitable timers,
//we have to share one for all axes. To do this, each axis maintains the time of its last step
//in move_state.{xyze}_time. This time is updated as the step is done, see early in dda_step().
//To find out which axis is the next one to step, the time of each axis' next step is compared
//to the time of the step just done. Zero means this actually is the axis just stepped, the
//smallest value > 0 wins.
//
//One problem undoubtly arising is, steps should sometimes be done at {almost,exactly} the same time.
//We trust the timer to deal properly with very short or even zero periods. If a step can't be done
//in time, the timer shall do the step as soon as possible and compensate for the delay later. In turn
//we promise here to send a maximum of four such short-delays consecutively and to give sufficient time
//on average.
X_AXIS_STEP (1 IO pin required) - To X-axis stepper driver
X_AXIS_DIRECTION (1 IO pin required) - To X-axis stepper driver
Y_AXIS_STEP (1 IO pin required) - To Y-axis stepper driver
Y_AXIS_DIRECTION (1 IO pin required) - To Y-axis stepper driver
Z_AXIS_STEP (1 IO pin required) - To Z-axis stepper driver
Z_AXIS_DIRECTION (1 IO pin required) - To X-axis stepper driver
EXTRUDER_STEP (1 IO pin required) - To extruder stepper driver
EXTRUDER_DIRECTION (1 IO pin required) - To extruder stepper driver
DISABLE_STEPPERS (1 IO pin required) - To X-axis, Y-axis, Z-axis, and extruder stepper drivers
ADC_MCP3208_CS (1 IO pin required) - To MCP3208 ADC
ADC_MCP3208_CLK (1 IO pin required) - To MCP3208 ADC
ADC_MCP3208_DATA_IN/ADC_MCP3208_DATA_OUT (1 IO pin required) - To MCP3208 ADC
SERIAL_LCD (1 IO pin required) - To Parallax 4 x 20 Serial Backlit LCD
PMC_IO0_DI (1 IO pin required) - To Propeller Memory Card
PMC_IO1_DO (1 IO pin required) - To Propeller Memory Card
PMC_IO2_WP (1 IO pin required) - To Propeller Memory Card
PMC_IO3_HOLD (1 IO pin required) - To Propeller Memory Card
PMC_SD_CS (1 IO pin required) - To Propeller Memory Card
PMC_FLASH_CS (1 IO pin required) - To Propeller Memory Card
PMC_SRAM_CS (1 IO pin required) - To Propeller Memory Card
PMC_CLK (1 IO pin required) - To Propeller Memory Card
MM74HC165_MM74HC595_CLOCK (1 IO pin required) - To daisy chained combo of MM74HC165 and MM74HC595 shift registers
MM74HC165_MM74HC595_DATA_IO (1 IO pin required) - To daisy chained combo of MM74HC165 and MM74HC595 shift registers
MM74HC165_LOAD (1 IO pin required) - To daisy chained combo of MM74HC165 and MM74HC595 shift registers
MM74HC595_LATCH (1 IO pin required) - To daisy chained combo of MM74HC165 and MM74HC595 shift registers
ESTOP_OVERTRAVEL (1 IO pin required)
EXTRUDER_HEATER (1 IO pin required)
EXTRUDER_FAN (1 IO pin required)
TABLE_HEATER (1 IO pin required)
29 IO pins required and utilized for time critical stuff
Since homing sensors are not time critical, these go to the spare channels of the ADC. Six spare channels available.
Since the user interface inputs and outputs (buttons and LEDs) are not time critical, these all get tied to the daisy chained MM74HC165 and MM74HC595. Eight inputs and eight outputs available.
I think this will do.
EDIT: Now I need to order a 4 x 20 Serial Backlit LCD from Parallax.
EDIT: Thanks Loopy and Kwinn for the idea of using the spare ADC channels.
EDIT: I see I forgot an IO pin for switching the extruder fan. This list above has been altered to include this IO pin.
Since I now believe that I have a one Propeller solution for a 3D printer, I am going to attempt a layout of a Propeller Proto Board. The main components of the layout will be a MM74HC165, a MM74HC595, a MCP3208 and a 13 pin header for a remotely mounted Propeller Memory Card. Meanwhile, I must also consider all of the necessary discrete components, various other headers for stepper drivers, push buttons, limit switches, LCD, LEDs, and other connections.
Since nobody has disagreed or agreed with my proposal of Post #71, I am assuming that either the proposal seems feasible or you are simply not interested
Either way, I go forth.
If by chance you are interested and are following along, let me point out a couple crucial points to this plan:
This plan assumes that stepper drivers have a step, a direction, and a disable pin, with the drivers being disabled by taking the disable pin to ground (I need to double check this).
DISCLAIMER: This plan and theory has not been tested, by purchasing the parts required and following along, you do so at your own risk, and I am by no way obligated to finish this plan. This plan is an evolving idea.
To assist me in going forward, I have created several image files, that will pertain to this project. I have attached these files to this post, so that others may choose their own placement of the required parts. As I go forward with this plan, I will create more image files and add them to this post. Additionally, I have provided a general image below to show some of the available images in the attachment. The image below, does not represent a current layout, it is only intended to show you what can be done with the files available. To use these files for a mock-up board, you will need an image editor. The files contained within the ZIP folder are in JPEG file format.
Additonally, I previously stated in this thread that I would not be using IC sockets, however I have changed my mind. The attached image files give you the choice of socketed or unsocketed ICs.
I'll read your thread from the beginning later - I am quite curious about a prop driven CNC as I will be ordering a CNC soon.
Unless you need the '165 and '595 specifically, you would probably be better off with an MCP23S017 - much greater flexibility, needs fewer prop pins. I use them (and the i2c variant - if its fast enough for your purpose, save prop pins) often.
Since I now believe that I have a one Propeller solution for a 3D printer, I am going to attempt a layout of a Propeller Proto Board. The main components of the layout will be a MM74HC165, a MM74HC595, a MCP3208 and a 13 pin header for a remotely mounted Propeller Memory Card. Meanwhile, I must also consider all of the necessary discrete components, various other headers for stepper drivers, push buttons, limit switches, LCD, LEDs, and other connections.
I noticed in the spec that there is just 1 end-stop sensor (ESTOP_OVERTRAVEL (1 IO pin required)), correct?
Is the assumption that the stepper motor controller portion of the project will monitor stepper positions and "know" the limits of each axis? The Printrbot Jr. that I use (a very inexpensive model) has end-stop/over-travel sensor switches for X, Y & Z axis.
Does the design somehow handle end-stop/over-travel discovery and recovery for all axis that I am missing? Just curious!
Unless you need the '165 and '595 specifically, you would probably be better off with an MCP23S017 - much greater flexibility, needs fewer prop pins. I use them (and the i2c variant - if its fast enough for your purpose, save prop pins) often.
Thanks for the tip Bill, I will look into that IC.
@dgately
I noticed in the spec that there is just 1 end-stop sensor (ESTOP_OVERTRAVEL (1 IO pin required)), correct?
Is the assumption that the stepper motor controller portion of the project will monitor stepper positions and "know" the limits of each axis? The Printrbot Jr. that I use (a very inexpensive model) has end-stop/over-travel sensor switches for X, Y & Z axis.
Does the design somehow handle end-stop/over-travel discovery and recovery for all axis that I am missing? Just curious!
The machine that I am designing will have X, Y, and Z over-travel swicthes wired in series with the E-stop, all being normally closed. If a single over-travel switch is tripped or the E-stop button is pressed causing the circuit to open, the machine will be halted.
As I see it, the machine, through programming, will only be allowed to travel within it's work envelope. However, if there should be a programming error of some sort, the over-travel switches will be constantly or periodically checked on a regular basis. The overall scheme of this idea goes back to this thread (http://forums.parallax.com/showthread.php/155345-CNC-Homing-And-Over-Travel-Discussion), but most particularly Post #40, however also referred to in numerous previous posts, within that thread.
The Teacup firmware constantly monitors the position of all axes, however at this point, I am not exactly sure what I am doing as far as the software goes, but the switches will be monitored. However I sure wish I had 3 or 4 more cogs.
Just in case anyone is curious..... Here is the current state of the layout.
Referring now to the illustration below:
The (4) 4 pin headers on the right of the board, are for connecting the stepper drivers for the X azis, Y axis, Z axis, and the extruder. As mention, STEP and DIRECTION will be controlled directly from IO pins, and all DISABLE(S) will be controlled through a transistor closing a ground. The light blue line represents the DISABLE(S) and I will finish the run later tonight, which will be connected to IO pin 8.
The 3 pin header located in the servo port area at the top of the board will be for connecting the serial LCD. Notice the red jumper to supply 5VDC to the port area.
The (4) 2 pin headers located at the extreme bottom of the board will be for the serial connection of (3) limit/over-travel switches of the X, Y, and Z axes, and the remaining one will be for an E-stop.
The 13 pin header is for connecting the Propeller Memory Card.
During the layout, I had to make a judgement call for space utilization. After trying several layouts with the various ICs, I decided to place the MCP3208 in it's current location, however this placement required the sacrificing of channels 1 and 2 of the ADC. I do not believe this will be a problem, because channels 8 and 7 will be used for thermistor readings, while channels 6, 5, and 4 will be used as homing switches, with channel 3 being an extra for additional circuitry as may be required for special circumstances. Coming off the top side of the ADC is (6) 2 pin headers for conecting to the ADC.
Still a lot more work and figuring to do, but hey, it is a start.
EDIT: As for the yellow wire going across the ADC, that will actually be a bottom connection, instead of crossing over the top of the ADC.
EDIT: During an image edit, I inadvertently left out one of the grounds on the left side of the 13 pin header. It only requires a jumper from pin 1 to pin 2.
While contemplating relaxation, I realized a quick fix for two more of the necessary connections. Instead of bringing outside voltages to the proto board, I will be using (2) solid state relays for the hot end heater and the bed heater. These relays can be activated with 3.3VDC, so I simply added a 2 pin header for each of them, on IO pins 10 and 11.
Please refer to the image below.
EDIT: The missing ground mentioned in the previous post, is now in place.
Just a heads up, because I am changing directions.....
I certainly don't want to make this layout more complicated than it really needs to be, and one thing is certain, I am running out of board space for IO expansion. So instead of using the 74HC165 and the 74HC595, or the IC that Bill suggested, I am going to opt for a similar IC to Bill's suggestion, and utilize the MCP23S08. The MCP23S08 is classified as a 8-Bit I/O Expander with Serial Interface. This IC is available in an 18 pin PDIP package, with 8 GPIOs, each of which can either be used as an input or an output. Basically, I believe this will make the layout of the board a lot less crowded and easier to place the additional required circuitry, however I also believe this will make the coding a little more complicated.
Considering that the homing switches will be wired to the ADC, the only thing that we need IO expansion for is a user interface. I think 8 GPIOs will provide ample pins for a user interface that simply consists of a few buttons and LEDs.
I do believe the layout is now getting very close to being capable of controlling a 3D printer or CNC machine. Of course there is still some more work that needs to be done on the layout, such as:
I need to review the circuitry on the spring bender for the DISABLE pins and finish the circuitry for that.
I need to determine and draw the circuitry for all items being connected to the ADC.
I need to determine and draw the circuitry for the extruder fan. Normally I stay away from pins 28 - 31, but I need one more pin for this fan, because I am now out of the remaining pins.
Some minor changes have taken place since my last post. The LCD has been moved to IO pin 8, and the DISABLE inputs for the stepper drivers will now be controlled by IO pin 9.
Anyhow, here is a current illustration of the layout.
While working on the layout this morning and pondering the ideal location and circuitry for the fan, it dawned on me that I was striving for the wrong location. Pertaining to a single extruder 3D printer, there should be three potential items that either require 12 or 24 VDC, which would include the hot end heater, the hot end fan, and the bed heater. Now I could be wrong, but I don't think so. Since all these items require a special voltage, not available on the proto board, I came to the conclusion of grouping the pins required for these items into (1) four pin header. Since I already had provisions at the top of the proto board for the hot end heater and the bed heater, I determined that the best place for the fan was right up there with them. By moving the fan up to this location, it became necessary to move the DISABLE(S) pin to the bottom of the board to be controlled by either pin 28, 29, 30, or 31, and pin 29 was tenatively selected. As it stands now and I believe this will be permanent, pins 9, 10, and 11, will control the hot end heater, the hot end fan, and the bed heater.
This layout could almost certainly also be utilized for a CNC controller, with the main differences being pins 9, 10, and 11, because a CNC router for example has no need for a hot end heater, a hot end fan, or a bed heater, however a CNC router could utilize these pins for other purposes, such as spindle control, pneumatic valves, and various types of soleniods. Please keep in mind that that it has not been verified whether there is enough cogs yet, but I do believe there will be enough memory with the Propeller Memory Card.
I am getting to the point, please be patient
Earlier in this thread, I discussed stacking stepper drivers and proto boards, at this point, that is all behind me, however one of the ideas mentioned pertaining to the stacking of the stepper drivers, can now be utilized to mount a necessary daugher board for CNC or 3D printing operations. Considering that this discussion is geared more towards a 3d printer, I will simply focus on a daughter board for a 3D printer, which will be mounted similarly to this discussion (http://forums.parallax.com/showthread.php/133309-Propeller-Proto-Board-Stepper-Motor-And-G251-Gecko-Drive-Tip). As I see it, the simplest possible solution would be to create a daughter board that accepts a regulated high amperage 12VDC supply from a wall wart or a another voltage from the main power and then regulated on board to produce 12VDC. The 12VDC would then branch off to three different control ciruits, being switched by either transistors or MOSFETs, and being controlled by pins 9, 10, and 11, and being capable of PWM. The switched circuits would then each go to a 2 pin header for proper distribution.
Anyhow that is my current plan and here is a current illustration of the layout.
If you are only using the MCP23S08 for switches and/or LED (ie relatively slow update devices) you could use the MCP23008 (which is the i2c version) saving you a pin.
Just a heads up, because I am changing directions.....
I certainly don't want to make this layout more complicated than it really needs to be, and one thing is certain, I am running out of board space for IO expansion. So instead of using the 74HC165 and the 74HC595, or the IC that Bill suggested, I am going to opt for a similar IC to Bill's suggestion, and utilize the MCP23S08. The MCP23S08 is classified as a 8-Bit I/O Expander with Serial Interface. This IC is available in an 18 pin PDIP package, with 8 GPIOs, each of which can either be used as an input or an output. Basically, I believe this will make the layout of the board a lot less crowded and easier to place the additional required circuitry, however I also believe this will make the coding a little more complicated.
Considering that the homing switches will be wired to the ADC, the only thing that we need IO expansion for is a user interface. I think 8 GPIOs will provide ample pins for a user interface that simply consists of a few buttons and LEDs.
If you are only using the MCP23S08 for switches and/or LED (ie relatively slow update devices) you could use the MCP23008 (which is the i2c version) saving you a pin.
To be perfectly honest, I almost opted for the MCP23008 version to save the pin, but I figured it was more complicated, however I really did not know, because I never messed around with i2c. Now I am wishing I had chose that version, because I really don't like the idea of using 28, 29, 30, or 31, and I am only 1 pin short for the layout. If I can find some good schematics and code, and providing it will not be too difficult to change the part in the layout, I will most likely change the current part for the ic2 version.
This post is in direct correlation with post #81 above.
To provide a better overall understanding and to show recent changes, I am now providing a new illustration. From the last illustration to this one, several things have changed, which are as follows:
Rerouted LCD wire and changed the color of the wire, to reduce wire color count.
The color coding for pins 9-12 have been changed to maintain an alternate green and yellow color coding for easy IO pin differentation.
The wire color for the DISABLE circuitry has been changed to reduce wire color count.
A simulation of the daughter has been added to this illustration, to aid in the description and purpose.
***Please note that the light blue wires do not actually exist and are just blobs of solder on the bottom of the proto board for making the necessary connection.
In the illustration below, you will see that the daughter board has been added to the VGA port area of the proto board. This daughter board will supply 12VDC to all the items that require this voltage on a 3D printer. The 4 pin header attached to pins 9, 10, and 11 of the proto board, will go directly to the 4 pin header of the daughter board, for the purpose of controlling three individual branches. These three branches will control the hot end heater, the hot end fan, and the bed heater, with each having their own 2 pin header on the daughter board for making the necessary connection.
You can share the CLK, MOSI & MISO between the MCP3208 and MCP23S08, as long as you make sure you are only accessing one of them at one time. That will save you three pins
To be perfectly honest, I almost opted for the MCP23008 version to save the pin, but I figured it was more complicated, however I really did not know, because I never messed around with i2c. Now I am wishing I had chose that version, because I really don't like the idea of using 28, 29, 30, or 31, and I am only 1 pin short for the layout. If I can find some good schematics and code, and providing it will not be too difficult to change the part in the layout, I will most likely change the current part for the ic2 version.
You can share the CLK, MOSI & MISO between the MCP3208 and MCP23S08, as long as you make sure you are only accessing one of them at one time. That will save you three pins
LOL.... You just had to throw that into the mix
That solution is very, very, enticing..........
From an IO standpoint, it seems the logical way to go, however from a machine standpoint, I am not so sure. Of course it would all depend on how the software was structured, and just how quickly ADC readings were required. I am not sure how common 3D printers operate, but I foresee the hot end and the bed heater warming up, just as soon as the machine is turned on, and I have not reached the point in determining how quickly I want the readings from the thermistors.
Note To Everyone:
Although this board has not been proven to contol CNC machines or 3D printers, so far the theory is pretty sound. I think the end result will all depend upon the number of cogs required to accurately control the stepper drivers. However, particularly pertaining to CNC equipment (3D printers excluded), it may become desirable to seperate the DISABLE pins for the stepper drivers, at which point, more IO pins will become a necessity, and the option that Bill suggests above, might prove to be a viable option. However, if this was to be used for a CNC machine, pins 9, 10, and 11, going to the daughter board, could perhaps be reclaimed for that purpose.
I think for now, I will just swap out the MCP23S08 for the MCP23008, and gain that single pin, because from all appearances, that is all I need, with the exception of more cogs It almost appears to be a drop in replacement.
Anyhow thanks for the tip and advice. LOL.... Talk about a fork in the road..... I hope I do not regret my decision
You don't need to be using fast SPI on this type of project. I2C is sufficient for the IO and ADC. The temperature even at 1 second reads is not important timing. You can drop all the SPI pins and switch to I2C on ALL input/outputs except for the stepper step/dir pins. That means pin 28/29 handle all inputs and all outputs including fans, enables, heaters, etc. A 16 IO device like the PCF8575 will give you 16 outs with extreme ease of use. You can have multiples of this device, I would dedicate 1 8575 to the inputs and 1 to all outputs(except step/dir). Then the 3208 stays on I2C as well. Even Spin I2C drivers are sufficient for watching over travel, but PASM drivers will speed up the reads. The 8575 needs pullups on the outputs, not a big deal and a resister network will help tidy up a breadboard or protoboard. This will simplify the layout and free up many pins. BTW, you speak about these "decisions" as if you are married to an initial idea for life... not very practical. Build something, test it, tweak it, rebuild it etc. For that matter, you can easily breadboard up the individual parts and get some code started for practice as well as start on each software "module".
Earlier you said that moving to the MCP23008 would save me one pin. I found a schematic elsewhere on the web, that only utilizes two pins, one for SCL and one for SCA. If this would work, than that would free up two pins for me, as compared to my previous layout with the MCP23S08.
If you would be so kind, could you please take a look at the illustration below and tell me if this would work. I have added two 10K resistors that were not shown in the schematic, because I read elsewhere that it was a good idea. Either way I am clueless.
I respect and appreciate your advice, I truly do, however I believe your recommendation is a bit over my head
I only need one more pin and I can start start soldering. By swapping out the MCP23S08 for the MCP23008, I get the pin I need, and perhaps another one. As mentioned, it is not the pins that worry me, it is the number of cogs available. Additionally, that would mean that I would have to basically scrap my entire layout and start fresh, with stuff I really know nothing about. As I have said many times, you electronic gurus amaze me. As for me, I just struggle through attempting to find a solution that works.
I am sure someone will be able to utilize your advice and create something better than what I am working on.
My suggestion is simpler than what you are currently discussing, in that you would have 1 I2C code block in Spin managing all IO(except step/dir). You do not need a cog for thermister, adc, heaters. Those are slow processes that can stay in a loop in Main. I2C with the device I mentioned is beyond simple. As far as getting 1 more pin, easily move the stepper disable to the I2C IO.
Comments
What did you think about Loopy's and Kwinn's idea about using the ADC to monitor switch and sensor input? Sounded pretty slick to me.
What type of GUI are you pursuing?
Now the GUI: I am on the way to use Qt. But the goal is to have a (mulit²) propeller based system that can run stand alone. And I have no doubt, P2 will be available the moment I need it.
The reason I replied to that point was that in two stop separate posts you appeared to say that you doubted it was possible. I made no claim as to which method would be better. I claimed nothing more than since everyone else did it in one thread we could if it made sense to do so.
The suggestion that implementing tinyg's movement algorithm was going backwards because the firmware don't fully support 3D printing I don't even understand. I promise I'm not being intentionally obtuse (it is 110% natural). The only way I understand that to make any sense is if you're suggesting we don't look at bringing forward better algorithms because nobody has done it before us.
On reading your posts for a long time that doesn't fit with the idbruce I know.
Red
And they may be right and I possibly could save some cog usage. At this point, I am just approaching it from the best way I know how, and what makes the most sense to me at the time. I have a pretty strict policy that I do not use code that I cannot read or understand. Since I have not learned PASM yet, that kind of rules that option out for me. To make it work well within the confines of SPIN, I believe 4 seperate cogs is the way to go.
I apologize red.... I believe better algorithms are very important.... And I certainly do not know it all, especially pertaining to 3D printing. However from what I understand, the slicer needs to be able to understand the algorithms utilized, to provide appropriate g-code. I code be wrong.
I've run sprinter, marlin and one other which escapes me and used slic3r, cura and a couple of other slicing toolchains over the years and never had an unsupported g-code issue.
Admittedly, I've not been active for 7 months or so so if that changed recently I'm unaware.
Support for arc primitives for example are considered expansions from the baseline g-code for examples but they're not generated explicitly unless to enable them.
In general you're on pretty safe ground. Everyone tries really hard to maintain backwards compatibility.
Get working with the basics them worry about the more advanced options.
If you need help with toolchain support for slic3r et al I can help with that too.
Bruce,
I believe that "to make it work well" in spin will be difficult. Spin is simply too slow to get performance at the "well" level. And having each axis in its own cog adds serious timing issues among the 4 axes. But also, to attempt 4 axes in a single cog using spin, I believe is futile, at least for a real working system. I believe for anything that can be described to work "well", you will need to use assembler.
Just my opinion based on my experience.
Cheers,
Peter(pjv)
The Gecko G251X is no couch potato. Utilizing counters, a ramp and step rate can be produced that the drive cannot keep up with. It has always been my intention, to use 4 counters in 4 seperate cogs. However I do not have it all figured out. I may have to resort to PASM in the long run.
EDIT: Or should I say that the motor and driver do not work above a certain frequency produced by a counter.
Where to begin????
Over the years, I have developed my own style of programming. I can't speak for others, but for me, when attempting to follow somone elses code, especially if it is difficult to understand, it usually helps me to get a better grasp, by editing the code and putting it into my style of programming. This ususually consists of rearranging the layout of the document, such as the amount indentation, line breaks, line spacing, parameter spacing, bracket placement, how and where comments are placed, etc.... In no way am I trying to say that the Teacup software is unreadable, I am just saying that it will be much easier for me to read and understand, if I adjust the layout to meet my style of programming. Before altering the content of these files, my first goal will be to alter the layout. This is not going to be a head over heels approach, but more of a as time permits approach, because I have plenty of other things to keep me busy. As an added benefit of editing the layout, you basically read and move every line of code, so you become very knowledgeable of where various sections are located.
After altering the layout of these files, I will then begin to change all the data types to match the definitions as established by Visual Studios C++. I believe when I get to this point, I will have a very thorough understanding of the software, and can make various other changes that I may deem necessary. Additionally at this point, I believe they will be some very nice files to have in my possesion, and should be easily adaptable to other files that I already have.
//How is this ACCELERATION TEMPORAL expected to work? All axes work independently of each other, //as if they were on four different, synchronized timers. As we have not enough suitable timers, //we have to share one for all axes. To do this, each axis maintains the time of its last step //in move_state.{xyze}_time. This time is updated as the step is done, see early in dda_step(). //To find out which axis is the next one to step, the time of each axis' next step is compared //to the time of the step just done. Zero means this actually is the axis just stepped, the //smallest value > 0 wins. // //One problem undoubtly arising is, steps should sometimes be done at {almost,exactly} the same time. //We trust the timer to deal properly with very short or even zero periods. If a step can't be done //in time, the timer shall do the step as soon as possible and compensate for the delay later. In turn //we promise here to send a maximum of four such short-delays consecutively and to give sufficient time //on average.Whereas we have the benefit of multiple counters.
X_AXIS_DIRECTION (1 IO pin required) - To X-axis stepper driver
Y_AXIS_STEP (1 IO pin required) - To Y-axis stepper driver
Y_AXIS_DIRECTION (1 IO pin required) - To Y-axis stepper driver
Z_AXIS_STEP (1 IO pin required) - To Z-axis stepper driver
Z_AXIS_DIRECTION (1 IO pin required) - To X-axis stepper driver
EXTRUDER_STEP (1 IO pin required) - To extruder stepper driver
EXTRUDER_DIRECTION (1 IO pin required) - To extruder stepper driver
DISABLE_STEPPERS (1 IO pin required) - To X-axis, Y-axis, Z-axis, and extruder stepper drivers
ADC_MCP3208_CS (1 IO pin required) - To MCP3208 ADC
ADC_MCP3208_CLK (1 IO pin required) - To MCP3208 ADC
ADC_MCP3208_DATA_IN/ADC_MCP3208_DATA_OUT (1 IO pin required) - To MCP3208 ADC
SERIAL_LCD (1 IO pin required) - To Parallax 4 x 20 Serial Backlit LCD
PMC_IO0_DI (1 IO pin required) - To Propeller Memory Card
PMC_IO1_DO (1 IO pin required) - To Propeller Memory Card
PMC_IO2_WP (1 IO pin required) - To Propeller Memory Card
PMC_IO3_HOLD (1 IO pin required) - To Propeller Memory Card
PMC_SD_CS (1 IO pin required) - To Propeller Memory Card
PMC_FLASH_CS (1 IO pin required) - To Propeller Memory Card
PMC_SRAM_CS (1 IO pin required) - To Propeller Memory Card
PMC_CLK (1 IO pin required) - To Propeller Memory Card
MM74HC165_MM74HC595_CLOCK (1 IO pin required) - To daisy chained combo of MM74HC165 and MM74HC595 shift registers
MM74HC165_MM74HC595_DATA_IO (1 IO pin required) - To daisy chained combo of MM74HC165 and MM74HC595 shift registers
MM74HC165_LOAD (1 IO pin required) - To daisy chained combo of MM74HC165 and MM74HC595 shift registers
MM74HC595_LATCH (1 IO pin required) - To daisy chained combo of MM74HC165 and MM74HC595 shift registers
ESTOP_OVERTRAVEL (1 IO pin required)
EXTRUDER_HEATER (1 IO pin required)
EXTRUDER_FAN (1 IO pin required)
TABLE_HEATER (1 IO pin required)
29 IO pins required and utilized for time critical stuff
Since homing sensors are not time critical, these go to the spare channels of the ADC. Six spare channels available.
Since the user interface inputs and outputs (buttons and LEDs) are not time critical, these all get tied to the daisy chained MM74HC165 and MM74HC595. Eight inputs and eight outputs available.
EDIT: Now I need to order a 4 x 20 Serial Backlit LCD from Parallax.
EDIT: Thanks Loopy and Kwinn for the idea of using the spare ADC channels.
EDIT: I see I forgot an IO pin for switching the extruder fan. This list above has been altered to include this IO pin.
Wish Me Luck.
Either way, I go forth.
If by chance you are interested and are following along, let me point out a couple crucial points to this plan:
- This plan assumes the use of a Parallax 4 x 20 Serial Backlit LCD for a display. (http://www.parallax.com/product/27979)
- This plan assumes that stepper drivers have a step, a direction, and a disable pin, with the drivers being disabled by taking the disable pin to ground (I need to double check this).
- This plan assumes the use of a Propeller Memory Card, being remotely mounted. (http://www.parallax.com/product/40004)
- This plan assumes that the user interface will be remotely mounted, which includes the LCD display, various buttons, and various LEDs.
- This plan assumes the use of a Propeller Proto Board. (http://www.parallax.com/product/32212)
- This plan assumes the use of a 74HC165 IC Parallel To Serial Shift Register. (http://www.parallax.com/product/602-00010)
- This plan assumes the use of a 74HC595 IC Serial To Parallel Shift Register. (http://www.parallax.com/product/602-00009)
- This plan assumes the use of a MCP3208 IC 8-Channel 12-Bit SPI Serial Interface A/D Converter. (http://www.parallax.com/product/604-00062)
DISCLAIMER: This plan and theory has not been tested, by purchasing the parts required and following along, you do so at your own risk, and I am by no way obligated to finish this plan. This plan is an evolving idea.To assist me in going forward, I have created several image files, that will pertain to this project. I have attached these files to this post, so that others may choose their own placement of the required parts. As I go forward with this plan, I will create more image files and add them to this post. Additionally, I have provided a general image below to show some of the available images in the attachment. The image below, does not represent a current layout, it is only intended to show you what can be done with the files available. To use these files for a mock-up board, you will need an image editor. The files contained within the ZIP folder are in JPEG file format.
Additonally, I previously stated in this thread that I would not be using IC sockets, however I have changed my mind. The attached image files give you the choice of socketed or unsocketed ICs.
I'll read your thread from the beginning later - I am quite curious about a prop driven CNC as I will be ordering a CNC soon.
Unless you need the '165 and '595 specifically, you would probably be better off with an MCP23S017 - much greater flexibility, needs fewer prop pins. I use them (and the i2c variant - if its fast enough for your purpose, save prop pins) often.
Best Wishes,
Bill
I noticed in the spec that there is just 1 end-stop sensor (ESTOP_OVERTRAVEL (1 IO pin required)), correct?
Is the assumption that the stepper motor controller portion of the project will monitor stepper positions and "know" the limits of each axis? The Printrbot Jr. that I use (a very inexpensive model) has end-stop/over-travel sensor switches for X, Y & Z axis.
Does the design somehow handle end-stop/over-travel discovery and recovery for all axis that I am missing? Just curious!
Thanks,
dgately
Thanks for the tip Bill, I will look into that IC.
@dgately
The machine that I am designing will have X, Y, and Z over-travel swicthes wired in series with the E-stop, all being normally closed. If a single over-travel switch is tripped or the E-stop button is pressed causing the circuit to open, the machine will be halted.
As I see it, the machine, through programming, will only be allowed to travel within it's work envelope. However, if there should be a programming error of some sort, the over-travel switches will be constantly or periodically checked on a regular basis. The overall scheme of this idea goes back to this thread (http://forums.parallax.com/showthread.php/155345-CNC-Homing-And-Over-Travel-Discussion), but most particularly Post #40, however also referred to in numerous previous posts, within that thread.
The Teacup firmware constantly monitors the position of all axes, however at this point, I am not exactly sure what I am doing as far as the software goes, but the switches will be monitored. However I sure wish I had 3 or 4 more cogs.
Referring now to the illustration below:
- The (4) 4 pin headers on the right of the board, are for connecting the stepper drivers for the X azis, Y axis, Z axis, and the extruder. As mention, STEP and DIRECTION will be controlled directly from IO pins, and all DISABLE(S) will be controlled through a transistor closing a ground. The light blue line represents the DISABLE(S) and I will finish the run later tonight, which will be connected to IO pin 8.
- The 3 pin header located in the servo port area at the top of the board will be for connecting the serial LCD. Notice the red jumper to supply 5VDC to the port area.
- The (4) 2 pin headers located at the extreme bottom of the board will be for the serial connection of (3) limit/over-travel switches of the X, Y, and Z axes, and the remaining one will be for an E-stop.
- The 13 pin header is for connecting the Propeller Memory Card.
- During the layout, I had to make a judgement call for space utilization. After trying several layouts with the various ICs, I decided to place the MCP3208 in it's current location, however this placement required the sacrificing of channels 1 and 2 of the ADC. I do not believe this will be a problem, because channels 8 and 7 will be used for thermistor readings, while channels 6, 5, and 4 will be used as homing switches, with channel 3 being an extra for additional circuitry as may be required for special circumstances. Coming off the top side of the ADC is (6) 2 pin headers for conecting to the ADC.
Still a lot more work and figuring to do, but hey, it is a start.EDIT: As for the yellow wire going across the ADC, that will actually be a bottom connection, instead of crossing over the top of the ADC.
EDIT: During an image edit, I inadvertently left out one of the grounds on the left side of the 13 pin header. It only requires a jumper from pin 1 to pin 2.
Please refer to the image below.
EDIT: The missing ground mentioned in the previous post, is now in place.
I certainly don't want to make this layout more complicated than it really needs to be, and one thing is certain, I am running out of board space for IO expansion. So instead of using the 74HC165 and the 74HC595, or the IC that Bill suggested, I am going to opt for a similar IC to Bill's suggestion, and utilize the MCP23S08. The MCP23S08 is classified as a 8-Bit I/O Expander with Serial Interface. This IC is available in an 18 pin PDIP package, with 8 GPIOs, each of which can either be used as an input or an output. Basically, I believe this will make the layout of the board a lot less crowded and easier to place the additional required circuitry, however I also believe this will make the coding a little more complicated.
Considering that the homing switches will be wired to the ADC, the only thing that we need IO expansion for is a user interface. I think 8 GPIOs will provide ample pins for a user interface that simply consists of a few buttons and LEDs.
- I need to review the circuitry on the spring bender for the DISABLE pins and finish the circuitry for that.
- I need to determine and draw the circuitry for all items being connected to the ADC.
- I need to determine and draw the circuitry for the extruder fan. Normally I stay away from pins 28 - 31, but I need one more pin for this fan, because I am now out of the remaining pins.
Some minor changes have taken place since my last post. The LCD has been moved to IO pin 8, and the DISABLE inputs for the stepper drivers will now be controlled by IO pin 9.Anyhow, here is a current illustration of the layout.
While working on the layout this morning and pondering the ideal location and circuitry for the fan, it dawned on me that I was striving for the wrong location. Pertaining to a single extruder 3D printer, there should be three potential items that either require 12 or 24 VDC, which would include the hot end heater, the hot end fan, and the bed heater. Now I could be wrong, but I don't think so. Since all these items require a special voltage, not available on the proto board, I came to the conclusion of grouping the pins required for these items into (1) four pin header. Since I already had provisions at the top of the proto board for the hot end heater and the bed heater, I determined that the best place for the fan was right up there with them. By moving the fan up to this location, it became necessary to move the DISABLE(S) pin to the bottom of the board to be controlled by either pin 28, 29, 30, or 31, and pin 29 was tenatively selected. As it stands now and I believe this will be permanent, pins 9, 10, and 11, will control the hot end heater, the hot end fan, and the bed heater.
This layout could almost certainly also be utilized for a CNC controller, with the main differences being pins 9, 10, and 11, because a CNC router for example has no need for a hot end heater, a hot end fan, or a bed heater, however a CNC router could utilize these pins for other purposes, such as spindle control, pneumatic valves, and various types of soleniods. Please keep in mind that that it has not been verified whether there is enough cogs yet, but I do believe there will be enough memory with the Propeller Memory Card.
I am getting to the point, please be patient
Earlier in this thread, I discussed stacking stepper drivers and proto boards, at this point, that is all behind me, however one of the ideas mentioned pertaining to the stacking of the stepper drivers, can now be utilized to mount a necessary daugher board for CNC or 3D printing operations. Considering that this discussion is geared more towards a 3d printer, I will simply focus on a daughter board for a 3D printer, which will be mounted similarly to this discussion (http://forums.parallax.com/showthread.php/133309-Propeller-Proto-Board-Stepper-Motor-And-G251-Gecko-Drive-Tip). As I see it, the simplest possible solution would be to create a daughter board that accepts a regulated high amperage 12VDC supply from a wall wart or a another voltage from the main power and then regulated on board to produce 12VDC. The 12VDC would then branch off to three different control ciruits, being switched by either transistors or MOSFETs, and being controlled by pins 9, 10, and 11, and being capable of PWM. The switched circuits would then each go to a 2 pin header for proper distribution.
Anyhow that is my current plan and here is a current illustration of the layout.
If you are only using the MCP23S08 for switches and/or LED (ie relatively slow update devices) you could use the MCP23008 (which is the i2c version) saving you a pin.
To provide a better overall understanding and to show recent changes, I am now providing a new illustration. From the last illustration to this one, several things have changed, which are as follows:
In the illustration below, you will see that the daughter board has been added to the VGA port area of the proto board. This daughter board will supply 12VDC to all the items that require this voltage on a 3D printer. The 4 pin header attached to pins 9, 10, and 11 of the proto board, will go directly to the 4 pin header of the daughter board, for the purpose of controlling three individual branches. These three branches will control the hot end heater, the hot end fan, and the bed heater, with each having their own 2 pin header on the daughter board for making the necessary connection.
LOL.... You just had to throw that into the mix
That solution is very, very, enticing..........
From an IO standpoint, it seems the logical way to go, however from a machine standpoint, I am not so sure. Of course it would all depend on how the software was structured, and just how quickly ADC readings were required. I am not sure how common 3D printers operate, but I foresee the hot end and the bed heater warming up, just as soon as the machine is turned on, and I have not reached the point in determining how quickly I want the readings from the thermistors.
Note To Everyone:
I think for now, I will just swap out the MCP23S08 for the MCP23008, and gain that single pin, because from all appearances, that is all I need, with the exception of more cogs
Anyhow thanks for the tip and advice. LOL.... Talk about a fork in the road..... I hope I do not regret my decision
Earlier you said that moving to the MCP23008 would save me one pin. I found a schematic elsewhere on the web, that only utilizes two pins, one for SCL and one for SCA. If this would work, than that would free up two pins for me, as compared to my previous layout with the MCP23S08.
If you would be so kind, could you please take a look at the illustration below and tell me if this would work. I have added two 10K resistors that were not shown in the schematic, because I read elsewhere that it was a good idea. Either way I am clueless.
My apologies for not replying quicker.
I respect and appreciate your advice, I truly do, however I believe your recommendation is a bit over my head
I only need one more pin and I can start start soldering. By swapping out the MCP23S08 for the MCP23008, I get the pin I need, and perhaps another one. As mentioned, it is not the pins that worry me, it is the number of cogs available. Additionally, that would mean that I would have to basically scrap my entire layout and start fresh, with stuff I really know nothing about. As I have said many times, you electronic gurus amaze me. As for me, I just struggle through attempting to find a solution that works.
I am sure someone will be able to utilize your advice and create something better than what I am working on.
Bruce