pyr0ball / pyr0piezo Goto Github PK

Is your feature request related to a problem? Please describe.
Some users reported confusion as to which orientation of the board is being used when describing features or connections

Describe the solution you'd like
Add an explanation and diagram to the docs site defining the usual board orientation.

Additional context
Originally suggested by maxcom

When I started rebuilding this mount in Fusion360, I mis-measured the hole spacing as 21mm square from center to center, when in fact the spacing is 23mm (when using the Toranado and a few other more common mounts)

Describe the bug
Sending RESET via a serial terminal resets the config values, but does not store them back to EEPROM, so on the next powerup, the values are not correct.

To Reproduce
Steps to reproduce the behavior:
Issue RESET via a serial terminal with 9600 baud rate.

Expected behavior
I expected the RESET method to execute and then store the entire config back to EEPROM.

Pyr0-Piezo (please complete the following information):

• Pp Version: EasyPiezi
• Board Revision: Rev.2.1.0
• Firmware Version: Latest

Eliminating floats from the code will free up roughly 30% of the flash. Currently floats are only used for setting voltage levels. This can be converted to millivolts to eliminate the need for floats.

Is your feature request related to a problem? Please describe.
Currently SJ1 is only needed for instances when the end-user is supplying <6vDC to the EasyPiezi board.

Describe the solution you'd like
Documentation about what it's for, why and when to use it, and how to use it should be added to the documentation site

Additional context
Originally suggested by maxcom

The current PWM DAC output swings between voltages wildly due to inaccuracies with the ADC inputs, and because of #20 where the internal vRef is not being utilized.

On current Rev.2.0.1/2.1.0 hardware, this issue may be mitigated by reducing the increments that the ADC logic will attempt to adjust the PWM DAC output, as well as adding hysteresis.

Hysteresis can be added easily by subtracting an integer value from the Diff variables.

Lowering the increments that the DAC output will change can be accomplished by dividing the ADJ_COMP and ADJ_FOLLOW variables by a larger value

Conceptual feature enhancement:

User can send a command over serial to have the AVR self-configure for a specific kind of piezo sensor, alter voltage range thresholds, etc.

Needs:

• Acceptable voltage ranges for specific piezo sensors
• Suggested models / BOM
• Compatibility request list

Describe the bug
Title

To Reproduce

• Comment VERBOSE out
• Try to send something over Serial In that would have some output, like CONFIG
• There is no response

Expected behavior
MCU should send something back over Serial Out, like the current config

Pyr0-Piezo (please complete the following information):

• Pp Version: EasyPiezi
• Board Revision: [e.g. Rev.2.1.2]
• Firmware Version: 2.1.4.6

LM317 should only take an extra pin. Check to see if it can be fit into the existing footprint.

As higher temperatures cause a reduction in the effective output of piezo elements, when the sensor is used in an under-bed configuration, the gain of the input must be increased to compensate. As this temperature can be variable, the sensor needs to be able to detect the change and compensate automatically.

This can be accomplished in a few different ways:

• Direct user input
• Onboard thermal sensing
• Input from the printer's controller relaying it's bed temperature measurements

Is your feature request related to a problem? Please describe.
Back in #17 we switched the probe to having active low logic (following the endstop standard) however, many boards that have a dedicated "probe" input seem to have a hardware pullup resistor attached to the logic pin. This means that (with the current scheme of trigger logic) even if the probe board is disconnected, the trigger logic still shows as "open"

Describe the solution you'd like
As this is a hardware pullup on the control board side, this sensor needs to be able to accommodate both logic schemes. This will necessitate changing the trigger output function to be invert-able, as well as introducing a new serial input to invert the logic

Is your feature request related to a problem? Please describe.
Since the beta kits were shipped using bare piezo disks, end-users will need to solder their own wires to it.

Describe the solution you'd like
Need to add a guide on how to do this to the documentation site, either with images or a video.

Additional context
Originally suggested by maxcom

Currently there is a reverse voltage protection diode onboard, but more in-depth analysis will be needed to ensure all voltage entry points are covered.

Currently there is a 0ohm resistor in place of a fuse, but to complete the overvoltage protection, a zener diode is required. Example

A quick rough search turned up this as an optional component

Is your feature request related to a problem? Please describe.
Custom tailored boards are hard to get.

Describe the solution you'd like
A solution would be to separate generic microcontroller part (e.g. use arduino nano) from specific part (LM2902 opamp).
This can be achieved by using DIP components on either breadboard or better simple PCB.

Describe alternatives you've considered
An alternative would be design single sided PCB with SOIC to be etched at home.

Additional context
Is there a plan or interest in doing such design?
How about current v2.x schematics, is it pretty much stable or subject to change?

Current sketch uses 5900 bytes, well over the 4kb limit of the mega48.

Refactor using low-level code will be required to fit the sketch on the smaller flash size, or switch to mega88+ may be required

Currently the trigger output pulse tied to the piezo interrupt function is partially governed by the delay length of the main loop function. I believe this may be part of what's causing the auto bed level on the Monoprice Delta Mini to prematurely trigger on the second tap. To fix it, I need to separate the actual pulse length out from the loop delay duration, and make sure there are some checks in place that assure the trigger delay function doesn't exceed the length of the loop delay to avoid a premature cutoff.

Migration from AVR to ATSAMD MCU will allow for onboard USB for debugging, firmware update, and parameter configuration, as well as incorporating a vastly increased operation speed, and hardware DAC output.

Currently the firmware logic doesn't directly account for the VCC input voltage of the circuit, but instead polls only the amp circuit for adjustment data. This has shown to cause instability with the voltage adjustment output.

Switching on the internal vRef and getting VCC polling will allow the ADC logic to be more precise and anticipatory of voltage fluctuations, without getting the big swings that occur from referential polling.

Original schematic for this board does not include some required pins. The 20qfn version of the CP2102 does not have a DTR pin required to send proper reset signal to the AVR during programming.

Need to switch to 24qfn or 28qfn and add a couple of extra passive components

References:
http://forum.arduino.cc/index.php?topic=180861.0

Rerap 2 and 3 firmware configuration data missing.

Is your feature request related to a problem? Please describe.
The method used to sense Vcc relies on the internal 1.1v reference built into the Atmega core. There's minor drift in voltage between IC's

Describe the solution you'd like
This can be compensated for in the software by changing the "voltMeterConstant" variable.

Currently this can only be set by changing the constant value in the firmware source, but I think adding a function to update it and save to EEPROM would make the process much less painful.

Additional context
Method to calculate the correct voltmeter constant:

The reading can be fine-tuned by using a multimeter, and this equation:

scale_constant = internal1.1Ref * 1023 * 1000

where

internal1.1Ref = 1.1 * Vcc1 (per voltmeter) / Vcc2 (per readVcc() function)

This is an enhancement on the FFC version boards that will introduce a replacement for the housing on the x-axis motor on Creality style gantries.

This housing typically holds the x-min endstop in place. The board will replace the housing covering the x-motor's drive gear, and will integrate the endstop and a breakout for the x-motor, while acting as a right angle turn for the FFC chain.

This will have two main benefits:

• Integration of the x-axis signals eliminates another messy cable
• an intermediary board allows for two shorter FFC cables which are easier and cheaper to source

Setting the sensor up as an i2c slave will allow to accept input form 3d printer controller as a peripheral device without needing to tie up a UART connection

Currently when attempting to insert the LM8UU size linear bearings into the upper mount slots, there is not enough tolerance to get them in. I'll need to build in a channel/cutout to give them enough space to be installed

Expected behavior: The PWM duty cycle for VComp_Adj and V_Fol_Adj should be at or close to the desired values set in the parameters section

Actual behavior: They both drop to 0 on boot

I expect something with the logic I wrote isn't doing it's job right. Will require review

At the moment the only mount I've designed is for the only printer I have one of these installed on. I do have access to a CR-10, Tevo Tarantula, and Davinci Jr, however and will be designing mounts for each of them.

I would also welcome help from the community on this part!

Describe the bug
When sending new configuration parameters over UART, the user either needs to send the command twice, or wait for a period of time (roughly 4-5 minutes) before the new parameter will be reflected in the board's behavior. If the board is reset, using the reset pin and not just power loss, these two parameters get 0'd out and will not work again til that delayed execution time is passed, or new parameters get sent.

To Reproduce
Steps to reproduce the behavior:

Send a command to change VFOL or VCOMP over serial while DEBUG is enabled. ADC readings will not change for a while unless the user sends another command editing the same parameter.

Expected behavior
When a parameter is sent over UART, the changes should be immediate

Pyr0-Piezo (please complete the following information):

• Pp Version: EasyPiezi
• Board Revision: Rev.2.1.0
• Firmware Version: v2.1.5

Is your feature request related to a problem? Please describe.
Currently there's no available documentation explaining what effects changing each parameter over serial will do

Describe the solution you'd like
Need a detailed document describing each parameter, what it's effects are, and what implications it has for the sensor behavior

Is your feature request related to a problem? Please describe.
Currently the parts library used in this project is attached to my personal Autodesk account, and not publicly accessible

Describe the solution you'd like
Eagle recently added functionality allowing "shared folders" including managed libraries. Will need to work on integrating this into the project

When I started on #29 I basically just separated out the functions and variables into separate files to avoid needing to scroll so much, but I added things in a wonky way. The code needs some revisiting and I'll need to rebuild some of the structure into a proper library so other devs can use it for their firmware if needed

Is your feature request related to a problem? Please describe.
Currently there is no documentation on the PT100 sensor integration

Describe the solution you'd like
Create documentation for:

• PT100 circuit diagrams
• Hookup guides
• General explanation of how it works

Additional context
Originally suggested by maxcom

Describe the bug
The ready light on the 2.1.0 beta board doesn't light up unless the piezo element is first tapped.

To Reproduce
To reproduce the behavior, the printer is first turned on, the beta board then boots up and ready light flashes, and then remains off until a tap on the piezo element by a finger causes the green light to light up and remain lit and ready to use for a homing or probing procedure.

Expected behavior
I expect for the ready light to light up and remain lit after the printer is powered up.

Printer Used:

• Manufacturer:
  Creality
• Model:
  Ender-3
• Control Board:
  Azteeg X5 Mini V3 Ethernet
• Firmware:
  Klipper

Pyr0-Piezo:
2.1.0 beta board

Is your feature request related to a problem? Please describe.
Currently the only branding on the board is the logo. A website would help users find documentation and support if needed

Describe the solution you'd like
add docs.pyroballpcbs.com to the silkscreen

Additional context
Originally suggested by maxcom

Documents for PCB assembly are needed:

• DXF simplified drawing of PCB components, front/back
• component type/value list
• recommend assembly order
• PCB reflow thermal profile
• initial programming / bootloader install
• firmware update procedure
• Marlin Configuration Guide
• Repetier Configuration Guide
• RRFW Configuration Guide
• Connection / hookup Guide - RAMPS
• Connection / hookup Guide - DuetWifi
• Connection / hookup Guide - Creality OEM Board
• Connection / hookup Guide - MKS Series

The sensor's current firmware is using active-high logic for z-min triggering. For safety, this logic should be inverted as a frayed wire or other connection issue will be apparent and the printer will refuse to move, rather than missing a high signal and causing a head crash or other damage

Incorporate circuits for K-type thermocouples and PT100 sensors:

Requires addition of a 4th amp to the circuit. Options:

• MCP6001 can be switched out for a second LM358.
• Amp could be installed at the control board side
• Stack an additional board on top of first using standoffs
  • requires pogo pads or other means by which to connect the boards together, or alternatively a second FFC

Having the board revision silkscreened on the board will make guessing the board revision from the schematics a thing of the past. Although I do enjoy going through all of the revision schematics, this is probably necessary.

Is your feature request related to a problem? Please describe.
Currently every contributor / user has to set up their own build environment if they want to modify the firmware. This is not easy for many people.

Describe the solution you'd like
A script, either interactive or entirely automated, would go a long way in synchronizing these environments

Describe alternatives you've considered
a setup guide might also work

Additional context
On Windows, this will require either bundling a wget binary, utilizing powershell, and handing the actual install script off to a posix-like environment like MingW64, or some combination of those

After fixing #19 a new issue showed up, which is that the analog reading serial output is only showing 1.00 regardless of the actual output.

Probing shows 3.84v and 4.22v on V_FOLLOW and VComp respectively

This behavior was observed on the bench testing platform (using an Atmega2650) until hysteresis and a few other enhancements were added in #24.

Currently those enhancements have not yielded the same results on the Rev.2.0.1 production boards. Screencap of the current PWM output behavior:

It's possible the slower clock speed of the At88 vs the At2560 is a factor, as the ADC is getting fewer checks and less able to correct for overshoot compared, or there could be other unforseen factors like PCB layout and capacitor type.

First steps will be to reduce the delay for polling the ADC pins to see if that improves the behavior, other tests will probably reveal other solutions

When the standalone unit is supplied 5v on it's main input, the AVR does not get activated due to low voltage dropout. LDO appears to be responsible, as it requires 6v or more to work properly

79L05 Datasheet

As this project has grown in complexity, the main program file has started getting a bit cluttered. It's getting past time to follow other project standards and make use of cpp and h files for storing variables and functions

For printers with dual+ extruders, a new design will be needed. Options:

• Single board, more I/O, larger FFC cable
• Stacked second board, additional FFC cable in parallel

Currently the initial voltage thresholds set in the firmware are assuming a 5v input. Upon boot, the controller should sense Vin, and adjust thresholds lower if Vin is below a certain threshold

Current code for adjusting the comparator stage voltage reference is broken. Need to rework the code for adjusting the resistor ladder, or switch to using PWM + LPF

This is a part of the solution to #1

Gain for the circuit can be made adjustable by reassigning the linear resistor ladder currently used by the VRef adjustment to the Gain Amp voltage divider.

The current amplification factor is 3, (10k/3.3k), but several values can be created using this topology. I will need to build a test circuit and run some experiments.

Is your feature request related to a problem? Please describe.
Feature request is not directly related to problem #47, but it would potentially save people from crashes if a piezo wire gets broken or element damaged.

Describe the solution you'd like
Upon powerup, the piezo board can interrogate the PCB header where the piezo element plugs into to see if anything is attached. This would be done in a function call that can be later reused, as described below.

The MCU can additionally poll every X amount of seconds or (however long is determined to be best) to verify that a piezo is still plugged in and that a wire or solder joint has not broken. This would cause the user to investigate their wiring to fix it when they realize their firmware cannot home or probe the Z axis, thus eliminating a crash.

This is one part of the solution to #1

Experimentation shows PWM DAC is a decent alternative to using the linear resistor ladder for VRef adjustment. Wiring will be fairly straightforward, as shown in the example below:

Experimentation showed that the topology best suited to the frequency generated by the Arduino's PWM is by using a 10k resistor, and parallel 3.3uF and 10uF ceramic capacitors. 22uF introduced a resonance waveform, and 10uF did not sufficiently smooth out the ripples.

On advice from a user on reprap forums (dc42) I will be increasing the adjustment ladder resolution by switching from it's current configuration (series ladder) to an R-2R parallel ladder configuration.

This will increase the number of possible values from 5 to 16 using the same number of pins. It should also allow for simplified code

Related to #1

Is your printer similar to any that currently already have support?
Like the Ender-3 Just a smaller cover / fan also screws to hold it is on the top

What mounting scheme do you plan to use?
Choose between: On-Printhead