Posts made by AJ Quick

@motomo Can't provide a Gerber as that was a prototype that didn't work.

@sebkritikel if you want to get super involved you can plug a keyboard and monitor in directly to the onboard PC inside the machine. If you run a few commands (I'm guessing sudo systemctl sshd enable) you can actually enable the SSH access into the machine and have full access to the files and commands. If I recall the hard drive contained the executable code for every model they had (Dimension, uPrint, Fortus).

You can also plug in over serial and send commands that would mimic the ones sent between the material bays and the controller. (Probably different for a Dimension or 1200 unit.)

@sebkritikel I know there are some technician only software tools out there that allow you to actually adjust the settings on the 1200/uPrint. I believe over command line you are also able to see some of those speed and acceleration parameters. That being said, I think the uPrint for example is very de-rated as far as what it is actually capable of. I would expect having to adjust the speeds and accelerations after conversion.

@archeantus Ahh that all makes sense. My first test was to do something similar. I had a Geckodrive G320 installed, several AC relays and made direct connections to the motors. I only abandoned that idea after I found one of the 120VDC power supplies was located directly on the PDB.

Using both seems to be the easiest solution.

@archeantus said in Another Stratasys uPrint retrofit:

Hey, I wouldn't have been able to get where I did without your work. Would you like to be added as a contributor to the project?

I've got a Hackaday account now, not sure what that entails: https://hackaday.io/ajquick

@archeantus said in Another Stratasys uPrint retrofit:

@aj-quick I run the motors directly from the Duet.

Would you be able to explain more? Mainly just what connections on the Duet are made to the PDB for the motor control? From the drivers directly? Any bypassing of the drivers on the PDB already?

@archeantus Absolutely impressive!

I would like to know how you have controlled the stepper motors directly from the Duet though the PDB. As I remember it, the onboard drivers take a PWM sine signal for control instead of regular step signals. Did you work out another way to do it using the Duet drivers directly!?

@mafco77, et al

I have received a lot of messages regarding this, so I figured I would post an update here.

I have not gotten any further with the Stratadue project.

The limitation remains determining how to control the steppers and servo motors through the Attiny85. Perhaps the Attiny85 was a bad choice in chip as I am using literally all the pins for IO and that means reprogramming can only be done via a high voltage programmer. If I were to continue, I would need to swap to a device with more pins or an Attiny85 in a DIP socket.

I cannot remember, but I believe the device requires a Duet2 with custom firmware. Not sure if my changes for the multiple expansion chips was ever merged into the main code or not. It's unfortunate that Duet3 came out soon after I started working on this and it doesn't appear to be compatible either. Bad timing unfortunately!

I do have a few PCBs built, but without the Attiny85 code, and custom Duet firmware, I'm not sure it would be of much use. I still have ~10-12 uPrint printers sitting around gathering dust too! I would love to get them up and running but I believe technology has advanced so much that newer / cheaper printers are leaps and bounds better.

@archeantus Very interested to see what you have accomplished!

This project is currently on hold. I had to go back to work on other things.

I have not yet ordered a new revision of the hardware as I need to make sure that the Attiny85 is actually capable of driving the servo and steppers in a robust manner. I worry that the processing rate of the Attiny is not fast enough for the servo motor. Tuning is very difficult. I have some control over the servo in a closed loop, but am worried about lost steps, overshoot and oscillation.

The latest design. Hopefully will be assembled and in-hand by the end of next week.

So many little changes between this version and the last. Namely: The Power Enable now uses a MOSFET to supply higher amperage to the Stratasys PDB.

New features:

-Control over the printer's main power supply. If the power switch is flipped off, the board will be able to keep it alive and go into a controlled shutdown. The Duet will be able to turn itself off in a controlled manner.
-Head Thermostat signal. There is an internal thermostat inside the printer's head that will trip if temperatures exceed a set point (100 degrees C). This is in addition to the head and chamber temperature alarms, and the three thermocouples.
-Bed Level Probe has an enable / disable. As it turns out you can turn the bed level probe on and off, so that it is only detecting when it is going through the bed leveling routine. This was discovered and added to this revision. Previously the bed probe was always enabled. I believe the reason for this is that the bed probe uses the signal to determine when the probe is stowed and then when it is sensing the presence of the bed.

Finally all uPrint printers (and presumably Dimension and Fortus) have a secret Machine ID eeprom located on the main body of the machine. This eeprom contains the serial number of the printer and the type of printer. On Stratasys machines, the hard drive contains the code to run all models of their printers. The eeprom tells the on-board computer what software to run. I found that the eeprom runs on a serial data bus, which the Duet2 has available. I figured I would breakout the signals and include an area where the signals could be read by the Duet2 should the need ever arise. The signals are by default not connected, but can be added by bridging the solder joint.

My thought is that it could be possible for the Duet2 to read the eeprom and verify what type of machine it is plugged into (uPrint, Dimension, Fortus) and then load the appropriate configuration. It is completely unnecessary though.

@ChrisP said in M308 and Current Loop Temperature Sensors

Good to hear! Yep CurrentLoop Temp Sensor fully implements the code for MCP3204 and 3208.

The only thing that's a little wonky about it is in that it wants you to input the Low and High values where High is the absolute maximum reading and the Low is 20% of the range.

I've written a simple formula for it to be calculated based on the desired Minimum value:

L=0.2 H + 0.8 MinVal

For example if your range is from 50-120 degrees:

0.2 * 120 + 0.8 * 50 = L

L = 64
H = 120

You should be able to read from 16 ADC using only 5 pins.

@dc42 said in M308 and Current Loop Temperature Sensors:

Thanks, but I won't be able to consider your PR until development on 3.02 has started, because 3.01 is close to final now.

I assume you aren't implementing new features until 3.02? I was hoping this and my SX1509 expansion code were ready to go for the next full release.

My code for re-using the chip-select pin between multiple SPI sensors is now ready as well:

https://github.com/dc42/RepRapFirmware/pull/383/files

This change is simple and is forwards / backwards compatible with existing RRF3 configurations.

Also includes a bug fix for the CurrentLoopTemp sensors.

ajquick opened this pull request in dc42/RepRapFirmware

open Allow Chip-Select Pins to Be Used by More than One Sensor. #383

I was able to do some testing of the thermocouples on the uPrint. I found that they output data on these ranges:

Chamber: 23 - 90 degrees C
Model and Support: 89 - 345 degrees C

These ranges are +/- 2-3 degrees, did not have a very accurate meter when measuring.

The test points on the PDC are adjusted so that 1V = 100 degrees, 5v = 500 degrees.. etc. But that is not the same signal that is output on the header J15.

Under normal operation, 80 degrees C is the max for the chamber and 330 degrees C for the model and support. It makes sense that it is capable of reading just outside of that range. No idea why they would put the bottom end of the range where they did.

@dc42 said in M308 and Current Loop Temperature Sensors:

I think the problem may be the "static" keyword at line 117 of CurrentLoopTemperatureSensor.cpp. I will remove it.

Bingo. That was it!

My best guess at what is happening is this:

Everything with the CurrentLoopSensor is configured properly.

-When CurrentLoopSensor issues SPI read command it is sent over the SpiTemperatureSensor.
-SpiTemperatureSensor requests a lock to use SPI with-in 10 (attempts? seconds? milliseconds?)
-If lock is successful, it sends the data out and receives the temperature data back.
-The temperature data that is sent back is always for the first defined sensor in the config, despite the data out presumably being correct.
-The data is correctly interpreted based on the Low / High settings and computed into a temperature.

Something in there is causing the SPI data to always come back as the first defined sensor. Perhaps the SPI lock isn't actually working? Are the other sensors trying to talk around the same time as the first sensor? It's reading the first sensor's data as if it were the data it had requested?

I'm assuming it will poll in order: Sensor 1 > 2 > 3, so Sensor 2 and 3 are seeing the data for Sensor 1 and assuming it is their own?

@dc42

Best I can tell, only one channel can be read at a time.

Theoretically, if you have two CurrentLoopSensors running on different chip select pins, wouldn't it schedule the SPI transactions so that they are never talking over each other?

It is odd that the first channel to be designated is always correct, the 2nd, 3rd, 4th.. etc. Are always tied to each other and produce the wrong data. Shouldn't they all be separated by the different instances of the sensor? Shouldn't the SPI transaction be treating each one as if it were it's own sensor running on SPI and keep them separated? I imagine it could be an SPI bug.

Here is what I did to test:

I changed my code to have 3 CurrentLoopSensors' each using their own chipSelect pin. I tied all 3 chip select pins together, so it doesn't really matter who is driving the signal. The same behavior exists no matter if it is using the code I just changed or the default RC8 firmware. It doesn't keep the SPI sensors separate.

EDIT: Just found what is going on:

It is only producing the ADC reading from the first defined sensor, it is just on the L/H scale that is specified.

Testing now. Those changes work, however any sensor that comes after the first are not reading the correct information.

M308 S0: Sensor 0 (Chamber) type Current Loop using pin (spi.cs5,duex.cs5,exp.50), reading 41.7, last error: success, channel: 2, temperature range 0.0 to 100.0C.
M308 S1: Sensor 1 (Model) type Current Loop using pin (spi.cs5,duex.cs5,exp.50), reading 201.6, last error: success, channel: 0, temperature range 109.5 to 330.0C
M308 S2: Sensor 2 (Support) type Current Loop using pin (spi.cs5,duex.cs5,exp.50), reading 201.4, last error: success, channel: 1, temperature range 109.5 to 330.0C

If I disable all except the Model for example. The temperature changes to the correct reading:

M308 S1: Sensor 1 (Model) type Current Loop using pin (spi.cs5,duex.cs5,exp.50), reading 109.5, last error: success, channel: 0, temperature range 109.5 to 330.0C

Seems the first sensor defined is always reading the correct number, but the 2nd or 3rd is always reading the wrong number. I suppose the SPI isn't actually queuing reads correctly? Further testing is needed.

This is what I've come up with:

https://github.com/dc42/RepRapFirmware/pull/380/commits/2ca324d3fd53f2988b4e2d95e878a2347b4065ee

Basically, add a new pin type of "chipSelect".

If it is of type chipSelect, it can be shared. When an SPI sensor makes a port, it assigns as type chipSelect. Now only other sensors can use that port for chip-select if it was previously used for chip-select. It should throw an error if any other code tries to use it for something other than chip-select.

This should allow CurrentLoopSensor to work while sharing the same chip-select and potentially can be used for other chips down the line.

ajquick opened this pull request in dc42/RepRapFirmware

draft CurrentLoopSensors can now have children sensors. #380

At a total loss here.

I am now understanding how the DHT sensor works, and it is not the same as how the MCP3204/8 works. DHT seems to always have the humidity value present, so it is a simple matter to just ask what that value is.

MCP3204/8 needs to treat each sensor as their own and communicate with the chip for each and every one. It also isn't something you can just change the channel and grab, since each sensor has its settings. I tried to allow AdditionalOutputSensor to configure the child sensor, but it just overrides the parent.

I suppose it would be possible to fully expand the CurrentLoopExtraSensor class to basically be a copy of CurrentLoopSensor, but that's not clean. There would be lots of code re-use.

The best thing I think that can be done is just to allow the SPI chipselect to be used by multiple sensors as long as the sensor is of the same type. At this time, I do not know how to accomplish that. I believe it should be safe to re-use chipselect pins, because they will automatically be queued and wouldn't be talking over each other. The worst case scenario is someone puts in the wrong chipselect and it cannot connect.

Current status:

Current-Loop-Extra currently works by assigning a child of the parent sensor. Unfortunately the child is an exact clone of the parent. No channel, differential or low and high parameters are passed.

This might just be a problem with "AdditionalOutputSensor.cpp" though. It probably only passes the "Y" parameter currently.

C/D/L/H cannot be assumed to be the same for the parent and the child. For example my thermocouples have different L/H ranges.