Bridgeport Retrofit - keyboard input delays noted

I doubt that you were confused but I surely was.

First a report on the 1st hack I did on Axis. I have used the machine a bit and can report that the delays still exists.

Next,up.
I put back 2973&4. I have 1756, 1765 and 1773 still commented out.

I have 3 axis displayed now. But sad to report the problem still exists.

I don't want to be a fly in the ointment and if this were not a potentially safety concern, I would live with the delay. It can be as much as 20 seconds. I can certainly take great care that each command typed in to the MDI is executed immediately and that each TouchOff is properly applied. Sometimes the machine just misses a motion command. Not really a significant problem. Nothing happened. The real problem is when there is a delay between the time I enter a movement at the MDI and it executes some time (up to 20 seconds) later. I have noticed that 2X. Good news I was not in the way.

While this type of problem is certainly well above my ability, I have looked a bit on in the developers archives and noted some discussion the Aug 2013 time frame. I can't tell for sure if there is work on the reported conflicting interaction between Axis and HALUI.

Does my testing indicate that my problem is not a result of this contention?

Thoughts on next steps appreciated.

Mark

I can go verify the lines specifically a little later. (doing my day job now. good thing i have a work from home job) I was pretty careful when I edited file and if memory serves, they all appeared to be relevant to spindle and feed override functions with the exception to those that I inadvertently commented out (subsequently reinserted).

To review. The PC being used is a Foxconn/Atom single core 1.6G processor now with 2G memory. It is not a clean build. It has been recently (10/14 or 15th) upgraded from master-rt. I can get the specific version if needed.

When I started down this path, I did do a clean install on a Dell 260 desktop that I had laying around. It has a single core processor running at 2.2G this Atom. Had 2G of memory. At the beginning I installed the MESA board into the Dell and moved my configs over etc. This was all done thinking that I was CPU bound somehow. Also a forklift upgrade seemed simple. When fully configured, I observed the same symptoms (albeit with slightly less delay) as with the Foxcomm/Atom.

After eliminating the PC as the issue, I went back to the Foxconn/Atom and all of the t/s has been done on it.

I can do a clean install on the Foxcomm/Atom box if you still think that would be helpful.

Mark

As I sit here naval gazing and waiting for my next teleconference to start it occurs to me that there is another set of functions that are still enabled which may be affected by this hypothetical contention between halui and axis.

I still have my shuttlepro hal config in effect and those shuttle hal connections are still contending with axis with regards to axis select, cont and incr jog. I wonder if I could/should comment out the lines in axis that make the axis select, incremental and continuous jog functions work on the screen.

Useless exercise or helpful?

Mark

In case anyone is following this drama I will provide a brief summary of today's actions and results.

I followed andypugh's advice and initiated LinuxCNC from the command line and set the debugger as suggested. I was amazed to see an endless stream of messages scroll by before I did anything with the machine. Didn't even take it out of estop, turn on or home it. The messages indicated that the system was receiving sro and fro change inputs when no controls were touched. Nothing was happening on the keyboard, shuttle, control panel switches and pots. I got on the IRC and consulted with andypugh to find that my results coincided with cradek expectations. He provided an number of suggestions including one that required me to make friends with HALSCOPE.

Today, with the use of HALSCOPE (after much grumbling, head scratching and false starts) I was able to identify there was a constant changing input to the halui fro and sro input pins as a result of my custom Hal code.

I modified my approach for handling my FRO/SRO pots and ultimately used the ilowpass component to resolve. Since I changed the code I have not seen the original symptoms. I have seen an occasional repeat of the "debugger scrolling messages" symptom which indicates to me that there may still be a problem that is just not apparent from the operator persecutive.

I'll go back to this tomorrow morning with a fresh perspective. I wonder if I will see the same performance or find out I was just fooling myself.

Mark

Thinking about this a bit more, it may be that my new code has covered up an electrical problem. Any fluctuations (ripple or noise) would be passed through my Hal code and come out the other side as a valid request for spindle or feed change. So without me adjusting either pot, my ripple/noise is being picked up at the input to the Mesa board, processed and passed to halui feed and spindle override counts pins. That constantly changing input is looking like a constant request to change the rates.

My new code essentially dampens the effect but doesn't eliminate the true cause.

Think I will explore the 24v field supply.

Mark

I did a little work this morning before the football games started. I attempted to isolate the random events easily identifiable using the debug task function (Issuing EMC_TRAJ_SET_SPINDLE_SCALE -- (+233,+20,+101413,0.933600,) with no adjustment made to spindle override. I get the same type of error message indicating adjustment seen by a mysterious feed rate adjustment too. I just didn't copy that line for this post.

Thinking I may have a electrical problem such as noise or ps ripple I ultimately used a ripple/noise free device, a 9V battery as the input to the mesa 7i77 board. There. No possible ripple or noise coming from that battery. Any change in feed or spindle rates must be coming from something else.

I noticed the randomly generated debug messages and finally captured an event on the halscope. The attached screen capture is with the a 9V battery tied to the 7i77, TB7, pin 1 and 2 , the first 2 analog input pins when using Mode 2. I am using Mode 2 using this in my pncconf generated hal file. loadrt hm2_pci config=" num_encoders=3 num_pwmgens=0 num_3pwmgens=0 num_stepgens=0 sserial_port_0=10000000 "

So with a steady ripple free input I have some unexplained events occurring.

Attached is the new code handling the feed and spindle override functions.

It is puzzling how with a solid input to the 7i77 I can still see the 150mV transients and the occasional ~300mV one as you can see from the scope trace. Its the 300mV one that caused the output of the float->s32 converter to transition from 9-8 and back to 9 which triggered an error message related to feed change that I saw on the debugger.


Am I all wet? Any ideas?

Mark

Ok, as I look over the halscope plot, with a 9V battery supplying the analog signal to the mesa 7i77 board input and the hm2 analog output from the mesa board loaded with spikes, I can only assume this is MESA related and something PCW / Pete would be the man to look this data over.

The spikes are surely not on the 9v battery but are on the output of the mesa board. Sounds like the spikes are being generated / added by the mesa board to me.

George