Quote
benj919
The (probably/hopefully) last step before I start printing is to modify the power on/off routine to disable the steppers directly instead of turning off the power supply to keep the sd card working.

One step forward, one step back...
Shutting only the steppers off instead of the power supply was easy enough.

It seems that even though the heaters are handled by the extruder board, the place holder pins used on the motherboard are used/initialized for the heaters anyway causing the one stepper using those same pins to behave erratic. hence I'm looking for a solution to that.

Could you advice me a strategy to change teacup firmware to drive laser module?
Laser module has 0..5v ttl driver, so it's possible to manage it with any PWM.

Which parts of firmware should i modify to drive choosen leg?
i think i need following changes:
a M code to switch on\switch off the laser, and to set laser beam intensity.

i'd like to use standard g-codes, getting from unmodified slicers. I think the best way is to switch laser when E extrudes, and switch off on moves w-o extrusion.

What i'm planning to do:
- a global var to hold current laser power
- changes around dda structure, to hold move's laser power
- config changes to define LASER_PIN and overal LASER scenario usage
- and how could i hook to E-Step inside a firmware? i think some kind of 'impulse', but they should last several loops, and i have no idea how things like that could be implemented.
Could you advice me a bit?

Heaters use PWM already, so simply treat this laser like a heater without temp sensor and you're done. On/off is with M106, then.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks for your reply. i'm trying to avoid g-code modifications, if possible.
it will allow me to use standard issue slicers.
As far i've read in the code, to select moves with E activity, it's sufficient to modify just a couple places:


in dda_create():

if dda->nullmove -> dda->lpower=0
if (delta_um[E] == 0)
dda->lpower = 0; // no laser this move
else
dda->lpower = laserPower;

in dda_step():
if move_state.counter[E] < 0
e_step(); laserme(dda->lpower);
else
laserme(0);


Am i right? or there's much deeper logic i should consider?
and, of course, to write the laserme().
i'll try to hook it to the heater, to lessen the pain.

Yes, looks good. laserme() would be heater_set(), then.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

it's mostly working now using heater_set() approach, thanks!

The only problem i see, it's that i cannot set 'temp' to zero. there's always some small signal set, from the very start. any ideas? might it be due to pwm frew too high, for example? (laser recommended 10mhz).

Quote
keedley
The only problem i see, it's that i cannot set 'temp' to zero. there's always some small signal set, from the very start. any ideas? might it be due to pwm frew too high, for example? (laser recommended 10mhz).

With 'temp', do you mean temperature? Temperature doesn't matter if there's no temp sensor defined.

PWM frequency is far below 10 MHz. With FAST_PWM set it's around 70 kHz, without it's around 70 Hz.

Oh, did I ask you to provide the code already? Teacup exists because people like you contributed their work, so it'd be nice if you did so as well. You can have write access to the repo, just say so.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

i'm eager to share my efforts, but i'm completely new to git and i'm not sure i'm ready to play with it's branches magic right now.

for pwm i mean 10khz, my bad.

i've configured my laser as a HEATER_fan in firmware. so, it's possible to use M106 to drive the power.
After all, i figured the laser is much like DC_EXTRUDER in behaviour, so i've put my changes close to it's activity.

When the board starts, i got a short period of full signal - may be floating signal, or full PWM. Unfortunatelly, i've got no osci around to check. Then, laser stays at some minimal power value, unknown to me, but i see the spot. i could not 'zero' it by using M106 S0 or heater_set(0,0). if i drive laser using generic sketch on arduino pwm legs, it goes off completely.
This is a bit dangerous behaviour and i'd like to eliminate it in one or other way, just to make sure nobody will get hurt by a sudden laser blink on a poweron.

thanks for your firmware, it's so beautifully clean, so even such unexperienced lad like me could mess around and get the job done.

here are some results i've managed to get by using Teacup (and your generous help):




Thanks a lot for so much fun!

Ah, entirely forgot about DC_EXTRUDER. It should actually do what you want.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

seems like it does. i'm trying to figure out the source of small artifact dots. they are clearly visible on letters, for example. it's not dots from the model, it's a "stray exctrude", as i see.

These artifacts might be due to the laser being full on, while carriages are still accelerating. Adjusting laser power to actual speed is thinkable by using the E stepper motor pin instead of PWM, then keeping the pin on for a defined time (less than or equal to the time needed for the next E step) after each step.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I guess he means the small dots in the letters. Not the bigger strength in the beginning of a contour. Each letter and also each form of the former picture has a small dot inside.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

I am attempting to organize building several ultra low cost 3d printers for local hackersace group. My only personal experience so far with generic Geetech/Folger type using Marlin and Repertier Host. Primary goal ATM is to replace mega2560 with Uno/Promini and search led me here. Only half way through this thread but mostly outdated or undecipherable techno jargon.

One constraint is requirement to use ardunio IDE only. Following wiki to compile using 1.6.7 results in errors:

Arduino: 1.6.7 (Windows XP), Board: "Arduino Mega ADK"
E:\arduino-1.6.7\arduino-builder -dump-prefs -logger=machine -hardware "E:\arduino-1.6.7\hardware" -hardware "C:\Documents and Settings\r\Local Settings\Application Data\Arduino15\packages" -tools "E:\arduino-1.6.7\tools-builder" -tools "E:\arduino-1.6.7\hardware\tools\avr" -tools "C:\Documents and Settings\r\Local Settings\Application Data\Arduino15\packages" -built-in-libraries "E:\arduino-1.6.7\libraries" -libraries "D:\0arduino\libraries" -fqbn=arduino:avr:megaADK -ide-version=10607 -build-path "C:\DOCUME~1\r\LOCALS~1\Temp\build4f7e3bd52d4eaa7c435ecabdc9c2e016.tmp" -warnings=default -prefs=build.warn_data_percentage=75 -verbose "D:\0arduino\Teacup_Firmware\Teacup_Firmware.pde"
...
In file included from C:\DOCUME~1\r\LOCALS~1\Temp\build4f7e3bd52d4eaa7c435ecabdc9c2e016.tmp\sketch\temp.h:4:0,
                 from C:\DOCUME~1\r\LOCALS~1\Temp\build4f7e3bd52d4eaa7c435ecabdc9c2e016.tmp\sketch\analog.c:7:
C:\DOCUME~1\r\LOCALS~1\Temp\build4f7e3bd52d4eaa7c435ecabdc9c2e016.tmp\sketch\config_wrapper.h:20:21: fatal error: config.h: No such file or directory
 #include USER_CONFIG
                     ^
compilation terminated.
exit status 1
Error compiling.

Marlin package compiles and works fine. Any suggestions what might be the problem with Teacup? Any help would be appreciated.

Edited 1 time(s). Last edit at 01/29/2016 10:41AM by paula.

Looks like config.h isn't found.
You did Configtool settings, right?
I've managed to build the firmware by putting board and printer header files in the same dir as .ino file i build with Arduino IDE, and manually changing config.h to point to them.
It's some kind of path resolving issue in Arduino IDE environment, as i see

Quote
paula
One constraint is requirement to use ardunio IDE only.

Perhaps you should reconsider this constraint. Configtool is really helpful and should be easier to use than Arduino IDE.

If you insist on not using Configtool you have to create config.h manually. Contents is just two #include lines, one to the board- and one to the printer config file.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thank you. Wiki was not clear to me on that. Now with:

#include "config/board.ramps-v1.3.h"
#include "config/printer.mendel.h"

I get:

C:\DOCUME~1\r\LOCALS~1\Temp\build4f7e3bd52d4eaa7c435ecabdc9c2e016.tmp\sketch\temp.c:39:29: fatal error: thermistortable.h: No such file or directory

I'm sure configtools is the solution to this problem but unfortunately I have no control over the Arduino only requirement due to demands of funder and IMO overly restrictive institiutional rules. Path issues are not likely the problem since I'm using portable 1.6.7 and other packages compile fine with just unzip and click.

Before being directed here I spent many hours trying to understand Marlin code but not being a C expert didn't get too far. Specially dislike the C++ junk for reasons mentioned on first page. If someone could post or link to a file for generic 100k thermistor maybe this would work. I don't suppose transplanting the table that's embedded in Marlin into a file called thermistortable.h would work?

Quote
paula
C:\DOCUME~1\r\LOCALS~1\Temp\build4f7e3bd52d4eaa7c435ecabdc9c2e016.tmp\sketch\temp.c:39:29: fatal error: thermistortable.h: No such file or directory

thermistortable.h has to be created as well. Configtool does this on the fly, according to the given values of each thermistor. Also, there is no "generic 100k table", properties of thermistors vary wildly. Comparison resistor (typically 4K7 or 1K) has a big influence, too.

One possible solution to deal with your constraints is to use Configtool once to create the required files. Do a build, upload not neccessary. Then you have all required files and Teacup should build by other means (Makefile, Arduino IDE) fine.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
Do a build, upload not neccessary.

Thinking of it and IIRC, just saving config.h in Configtool is sufficient to create thermistortable.h.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

If this still doesn't work, the underlying tool used by Configtool is a command line tool:

python createTemperatureLookup.py --help

Using options is required, default values give a table, but not a usable one for any thermistor.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
there is no "generic 100k table", properties of thermistors vary wildly. Comparison resistor (typically 4K7 or 1K) has a big influence, too.

In my experience there is little variation among the 10 cent parts (http://www.ebay.com/itm/331695101646?). Couple percent at most. even from different sources. As far as the resistor it seems 4.7k is default for RAMPS and a defacto standard. Modified to 1k for those who work with nylon and other high temp filament. I have used the default tables in Marlin, Repetier, and couple other firmwares with no need to customize.

Accuracy is not biggest concern at this point but rather just getting Teacup to compile like Marlin and other standard Arduino projects. Even a dummy file or hint about the format required would be helpful. Would it work if this was transplanted into a file:

short temptable[NUMTEMPS][2] = {
   {1, 938},
   {11, 423},
   {21, 351},
   {31, 314},
   {41, 290},
   {51, 272},
   {61, 258},
   {71, 247},
   {81, 237},
   {91, 229},
   {101, 221},
   {111, 215},
   {121, 209},
   {131, 204},
   {141, 199},
   {151, 195},
   {161, 190},
   {171, 187},
   {181, 183},
   {191, 179},
   {201, 176},
   {211, 173},
   {221, 170},
   {231, 167},
   {241, 165},
   {251, 162},
   {261, 160},
   {271, 157},
   {281, 155},
   {291, 153},
   {301, 150},
   {311, 148},
   {321, 146},
   {331, 144},
   {341, 142},
   {351, 140},
   {361, 139},
   {371, 137},
   {381, 135},
   {391, 133},
   {401, 131},
   {411, 130},
   {421, 128},
   {431, 126},
   {441, 125},
   {451, 123},
   {461, 122},
   {471, 120},
   {481, 119},
   {491, 117},
   {501, 116},
   {511, 114},
   {521, 113},
   {531, 111},
   {541, 110},
   {551, 108},
   {561, 107},
   {571, 105},
   {581, 104},
   {591, 102},
   {601, 101},
   {611, 100},
   {621, 98},
   {631, 97},
   {641, 95},
   {651, 94},
   {661, 92},
   {671, 91},
   {681, 90},
   {691, 88},
   {701, 87},
   {711, 85},
   {721, 84},
   {731, 82},
   {741, 81},
   {751, 79},
   {761, 77},
   {771, 76},
   {781, 74},
   {791, 72},
   {801, 71},
   {811, 69},
   {821, 67},
   {831, 65},
   {841, 63},
   {851, 62},
   {861, 60},
   {871, 57},
   {881, 55},
   {891, 53},
   {901, 51},
   {911, 48},
   {921, 45},
   {931, 42},
   {941, 39},
   {951, 36},
   {961, 32},
   {971, 28},
   {981, 23},
   {991, 17},
   {1001, 9},
   {1011, -1},
   {1021, -26}
};

Or is the naming or format wrong? Can you say if there are other files missing that make Teacup incompatible with regular Arduino?

You will have to take my word for it there are logistical and political reasons why it would be difficult to use python utilities. BTW thanks to you and Triffid and all the others who worked hard to made this project what it is. Browsing this forum and internet in general shows hundreds of requests for ability to use Uno or Promini. Most no reply and never heard from again. I think gurus who are using Mega2560, Due, and other ARM may not appreciate the benefits. I really hope this can be made to work as there are many things I don't like about other firmwares besides that Mega328 issue..

Edited 2 time(s). Last edit at 01/30/2016 11:10AM by paula.

Here's my own current table file, one thermistor with 1K resistor, the other with 4K7:

$ cat thermistortable.h 

/**
  This file was autogenerated when saving a board with
  Teacup's Configtool. You can edit it, but the next board
  save operation in Configtool will overwrite it without
  asking.
*/

#define NUMTABLES 2
#define NUMTEMPS 25

#define THERMISTOR_EXTRUDER 0
#define THERMISTOR_BED 1

const uint16_t PROGMEM temptable[NUMTABLES][NUMTEMPS][2] = {
  // EXTRUDER temp table using Beta algorithm with parameters:
  // R0 = 100000, T0 = 25, R1 = 0, R2 = 1000, beta = 4092, maxadc = 1023
  {
    {   1,  6384}, // 1596 C,      1 ohms, 0.005 V, 0.02 mW
    {  43,  1636}, //  409 C,     44 ohms, 0.210 V, 1.00 mW
    {  85,  1344}, //  336 C,     91 ohms, 0.415 V, 1.90 mW
    { 127,  1188}, //  297 C,    143 ohms, 0.620 V, 2.68 mW
    { 169,  1088}, //  272 C,    199 ohms, 0.825 V, 3.42 mW
    { 211,  1012}, //  253 C,    261 ohms, 1.030 V, 4.06 mW
    { 253,   952}, //  238 C,    328 ohms, 1.235 V, 4.65 mW
    { 295,   896}, //  224 C,    411 ohms, 1.440 V, 5.05 mW
    { 337,   852}, //  213 C,    495 ohms, 1.646 V, 5.47 mW
    { 379,   812}, //  203 C,    591 ohms, 1.851 V, 5.79 mW
    { 421,   772}, //  193 C,    711 ohms, 2.056 V, 5.94 mW
    { 463,   740}, //  185 C,    829 ohms, 2.261 V, 6.17 mW
    { 505,   704}, //  176 C,    991 ohms, 2.466 V, 6.13 mW
    { 547,   672}, //  168 C,   1169 ohms, 2.671 V, 6.10 mW
    { 589,   644}, //  161 C,   1358 ohms, 2.876 V, 6.09 mW
    { 631,   612}, //  153 C,   1621 ohms, 3.081 V, 5.86 mW
    { 673,   580}, //  145 C,   1947 ohms, 3.286 V, 5.55 mW
    { 715,   548}, //  137 C,   2357 ohms, 3.491 V, 5.17 mW
    { 757,   516}, //  129 C,   2874 ohms, 3.696 V, 4.75 mW
    { 799,   480}, //  120 C,   3628 ohms, 3.901 V, 4.19 mW
    { 841,   444}, //  111 C,   4630 ohms, 4.106 V, 3.64 mW
    { 883,   400}, //  100 C,   6338 ohms, 4.312 V, 2.93 mW
    { 925,   348}, //   87 C,   9417 ohms, 4.517 V, 2.17 mW
    { 967,   276}, //   69 C,  17119 ohms, 4.722 V, 1.30 mW
    {1009,   132}  //   33 C,  69863 ohms, 4.927 V, 0.35 mW
  },
  // BED temp table using Beta algorithm with parameters:
  // R0 = 100000, T0 = 25, R1 = 0, R2 = 4700, beta = 4092, maxadc = 1023
  {
    {   1,  3284}, //  821 C,      5 ohms, 0.005 V, 0.01 mW
    {  43,  1076}, //  269 C,    208 ohms, 0.210 V, 0.21 mW
    {  85,   884}, //  221 C,    432 ohms, 0.415 V, 0.40 mW
    { 127,   784}, //  196 C,    672 ohms, 0.620 V, 0.57 mW
    { 169,   716}, //  179 C,    933 ohms, 0.825 V, 0.73 mW
    { 211,   660}, //  165 C,   1246 ohms, 1.030 V, 0.85 mW
    { 253,   620}, //  155 C,   1550 ohms, 1.235 V, 0.98 mW
    { 295,   584}, //  146 C,   1902 ohms, 1.440 V, 1.09 mW
    { 337,   548}, //  137 C,   2357 ohms, 1.646 V, 1.15 mW
    { 379,   520}, //  130 C,   2803 ohms, 1.851 V, 1.22 mW
    { 421,   492}, //  123 C,   3353 ohms, 2.056 V, 1.26 mW
    { 463,   468}, //  117 C,   3931 ohms, 2.261 V, 1.30 mW
    { 505,   444}, //  111 C,   4630 ohms, 2.466 V, 1.31 mW
    { 547,   420}, //  105 C,   5483 ohms, 2.671 V, 1.30 mW
    { 589,   396}, //   99 C,   6528 ohms, 2.876 V, 1.27 mW
    { 631,   376}, //   94 C,   7583 ohms, 3.081 V, 1.25 mW
    { 673,   352}, //   88 C,   9125 ohms, 3.286 V, 1.18 mW
    { 715,   328}, //   82 C,  11050 ohms, 3.491 V, 1.10 mW
    { 757,   304}, //   76 C,  13469 ohms, 3.696 V, 1.01 mW
    { 799,   276}, //   69 C,  17119 ohms, 3.901 V, 0.89 mW
    { 841,   248}, //   62 C,  21977 ohms, 4.106 V, 0.77 mW
    { 883,   216}, //   54 C,  29623 ohms, 4.312 V, 0.63 mW
    { 925,   176}, //   44 C,  43945 ohms, 4.517 V, 0.46 mW
    { 967,   120}, //   30 C,  79743 ohms, 4.722 V, 0.28 mW
    {1009,     4}  //    1 C, 332510 ohms, 4.927 V, 0.07 mW
  }
};

Two notes:

- 25 lines are entirely sufficient. More lines cost processing power at neglibile accuracy gain.

- Compared to a Marlin table, the right value is multiplied by four (for better accuracy if custom-created).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
paula
Browsing this forum and internet in general shows hundreds of requests for ability to use Uno or Promini. Most no reply and never heard from again. I think gurus who are using Mega2560, Due, and other ARM may not appreciate the benefits. I really hope this can be made to work as there are many things I don't like about other firmwares besides that Mega328 issue..

Yes, it's a typical constellation that developers have big equipment, users want something simpler/cheaper.

These small boards are actually just as fast as a Mega2560. Even displays are possible with them: [github.com] And Teacup is also the AFAIK only firmware fitting into the LPC1114, the only ARM chip in a DIY-friendly DIP package, e.g. used on this board: [reprap-diy.com]

If you happen to see such requests for Unos, feel invited to drop a line about Teacup there :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Will do. In fact I have already led a few of my real world buddies to this thread and we are working our way through. Due to school and work though it will probably take a couple weeks but worth is for the historical perspective.

Anyway the thermistor file fixed that problem but now I get:

C:\DOCUME~1\r\LOCALS~1\Temp\build4f7e3bd52d4eaa7c435ecabdc9c2e016.tmp\sketch\attic\accel_clock\dda.h:6:28: fatal error: config_wrapper.h: No such file or directory

I don't really know what "config_wrapper" is. Any hints? Auto-generated by configtool too? If so do you think there might be other auto-generated files to look out for?

Quote
paula
I don't really know what "config_wrapper" is. Any hints? Auto-generated by configtool too?

Nope, not auto-generated, but a regular source code file in the top level directory: [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Ok so I see it is present in the Teacup Firmware folder too so a mystery why the compiler starts looking in Temp for dda&config_wrapper. Maybe something screwed up with the IDE. However other complex projects like Multiwii and Marlin still compile ok so something is different with Teacup. When I get a chance try the configtool thing on my own PC but that will take a few days. If that fails in desperation reinstal a fresh XP and 1.6.7. Again.

This is why I dislike HLL programming in general. It seems hackers spend 2/3 of the time strugging with tools and dependencies and hardly any actually coding. It's enough to drive one back to assembly.

Quote
paula
a mystery why the compiler starts looking in Temp for dda&config_wrapper..

That's how Arduino IDE works. Before compilation, "everything" is copied to a temp folder, then stuff is compiled there. And yes, it's a limitation for more complex projects.

Another such unneccessary annoyance is that Arduino insists on the top level folder and the .ino file to have the same name.

Arduino is excellent for simple projects, limited for more complex ones.

Quote
paula
This is why I dislike HLL programming in general. It seems hackers spend 2/3 of the time strugging with tools and dependencies and hardly any actually coding.

Simply drop these tools :-) Compiling a firmware is no more complex than compiling any other software. Makefile works fine (in case your political constraints allow to use it), even with the compiler coming with Arduino. Configtool simply does the equivalent of 'gcc -c *.c' and links the resulting objects together. Could be done on a 5-line build script. Perhaps you're allowed to use a script.

Edited 1 time(s). Last edit at 01/31/2016 07:23AM by Traumflug.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
That's how Arduino IDE works. Before compilation, "everything" is copied to a temp folder, then stuff is compiled there. And yes, it's a limitation for more complex projects.

That does not align with my understanding of how the IDE, preprocessor, postprocessor, etc work. None of the other programs do anything important there until the end where obj and hex are generated. Looking at the log I posted above it seems that Teacup don't really use temp either until the very end where it crashes. Projects that are far more complex like Multiwii and Marlin compile fine so it looks to me that configtool or something in the code has broken compatibility with standard Ardunio IDE.

Quote
Traumflug
Could be done on a 5-line build script. Perhaps you're allowed to use a script.

I'm not a big fan of make but as long as it don't involve installing new unapproved software this should work. It would be a great help if you could put up an example. Maybe from there I can fix the compatibility issue. I suppose if necessary I could go all the way back to FiveD which does work with Arduino and start from there. Hopefully it won't come to that because I am not proficient in C. Or pick up where I left off with Marlin which I dread.

Edited 1 time(s). Last edit at 01/31/2016 08:04AM by paula.

Quote
paula
That does not align with my understanding of how the IDE, preprocessor, postprocessor, etc work. None of the other programs do anything important there until the end where obj and hex are generated. Looking at the log I posted above it seems that Teacup don't really use temp either until the very end where it crashes.

At least it's confusing. Things happen which are meant to make things easier, but don't always work. For example, files in subfolders aren't taken into account, so one has to make sure to have an entirely flat hierarchy. Also see this post of yours above: [forums.reprap.org] At that point, config_wrapper.h was found.

Teacup uses Arduino as pure build environment. Arduino library is entirely ignored. And it doesn't influence intentionally how this building happens.

Quote
paula
It would be a great help if you could put up an example.

How to build with the Makefile is described in the "Developer Installation" section in the wiki: [reprap.org]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I appreciate you taking the time to step me through this and your patience with my inexperience.

Make does not seem to be available in my default path so a bit of a problem. When I get home this weekend there will be opportunity to install Python on my own PC and give Configtool method a try. It will not be a final solution for the current group but maybe a way point getting Teacup working with regular Arduino.

Teacup seems to be oriented toward the more experienced users which is unfortunate because there are significant advantages over other firmware and it would benefit mainstream big time. Potential to run on Uno type controllers being foremost for us. Not having ability to update post #1 here is a liability since that is first exposure for most interested parties. If I make headway getting this to compile it might be a good idea to start another thread "Teacup for Dummies" where recent progress can be highlighted early and hand holding a little more appropriate.

BTW it's strange as you said config-wrapper.h is found when referenced directly but generates errors accessed through those "attic" files. I suppose it could be a bug in the IDE but other packages that are far bigger compile fine. More likely I suspect a problem with code. For example sometimes the difference between quotes and <> wreaks havoc when referencing include files. I hope I can resolve these issues one way or another before end of school year which is funding deadline.

Edited 2 time(s). Last edit at 02/02/2016 01:23PM by paula.