User Mike_Eitel on the forum reports a problem with his LCD on a 7i67e/7i73 after a recent upgrade of master: https://forum.linuxcnc.org/27-driver-boards/33856-7i73-lcd-shows-rubisch
We discussed it a bit on IRC here: http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2018-01-22.html
Looks like build 1:2.8.0\~pre1.3405.ge10c52ea6 was good, and build 1:2.8.0\~pre1.3520.g0a096c965 was bad. That range includes three patches to sserial.c that may be involved:
* 5c7fec0de922ef22fe48237633818d868c58abf2
* d92f69438023d62a66171a785a50d33f8cea32c6
* 31029ef2166d1f52745baa5b458358dd72fe91d4
@andypugh do you have any ideas here?
评论 (9)
#2 – gmoccapy 于 2018-02-18
OK, next test:
reseted master hard to be 6f0f2cafb89a914ea392c65d2e3dcbe754b1638d
(control.c: honor fractional accels for wheel jogging)
working correct!
reseted hard to d92f69438023d62a66171a785a50d33f8cea32c6
(Smart Serial: Start to enable parameter setting via HAL)
broken!
So IMHO that merge causes the problem.
Andy if you want me to make more checks, I will do that.
If you need a 7i76e for testing, I am able to borrow you one.
Norbert
Note: If I stop the script, the display is holded and I can see, that all letters have moved 1 by right place, So you do not read LinuxCNC but LinuxCNCC, so that might be just a wrong counting in some place.
#3 – rene-dev 于 2018-02-18
can you open a halrun, and show the pins and parameters of the 7i73 in the working and non working config?
open halrun, and type show param, and show pin.
run the show command multiple times, and see if some values are changing.
#4 – rene-dev 于 2018-02-18
form the lcd man page: “The output byte stream is sent via this pin. One character is sent every thread invocation. There in no handshaking provided.”
maybe that is part of the problem?
#5 – andypugh 于 2018-02-18
sserial parameters are only written when the port transitions from stopped to run.
Even then the values should only be written if they have changed (and I have taken precautions to guard against apparent non-identical values in different-length floats)
I am wondering if it is possible that hm2_eth sometimes skips a byte.
#6 – rene-dev 于 2018-02-18
I thought about that after I hit send. The display stuff must be in the process data, as its updated every cycle. I dont think the ethernet skips a byte. That makes this bug even more strange, as process data are not affected by the commit…
#7 – pcw-mesa 于 2018-02-20
Maybe in the interim the sserial parameter access can be made conditional on a command line flag.
This could help debug the issue and also may save some time if you dont need the parameter access since it can add several seconds to LinuxCNC startup if you have a lot of sserial cards
#8 – andypugh 于 2018-02-20
The underlying problem is that I have only had 10 evenings at home since December and have already spent them all on this issue. (ie it us time, not technical difficulty that is causing the delay)
#9 – andypugh 于 2018-03-08
A post to the forum reports that after a number of bug fixes the LCD is now working properly.
None of the fixes applied were directly related to the commit at which the problem appeared. I can only assume that there was a second-order effect.
#1 – andypugh 于 2018-01-23
d92f694 is the only likely-looking one, but that involved a lot of code moving about, so seems unlikely to be diagnosed by inspection.
I am not likely to be in the same place as the hardware, with the time to look at it, for a few weeks.