General Notes

[freemanmaxwell]

What is Most Likely Happening

• The Nanonis VIs slow the program down.
• This is most obvious on the current graph, where the discrete steps are clearly visible.

How to fix:

• We'll have to go through each individual subVI until we find the one (hopefully) with all the lag, and if possible work around it.

[freemanmaxwell]

Try replacing 'current' VI with signal-get vi.

[freemanmaxwell]

If Setpoint, get rid of it. If current, try signal-get or removing it altogether and finding another source If Z position write, there's not much we can do. If Z position read, there's not much we can do.

[freemanmaxwell]

It turns out that running in parallel loops means that the arm is much more reliable. I suggest doing this regardless if there's a better way to fix it.

[freemanmaxwell]

Current loop time is about 6 ms per loop.

[freemanmaxwell]

When running in parallel loops, a nanonis-loop wait time of: >40 ms makes the arm unusable, 40 ms - 30 ms has some feedback but is the minimum threshold for usability, 30 ms - 0 ms is completely usable.

While I haven't measured the loop time, I suspect (rather, hope) that it is less than 40 ms. Effectively solving this problem.

[freemanmaxwell]

Unfortunately, it seems that doing it this way introduces bouncy feedback. I tried implementing a bandstop butterworth filter at the frequency it bounces, but the behavior became more erratic. It seems that with the right downward pressure on the pen, this feedback goes away. I'd say it's a problem for another day, but its extremely annoying.

[freemanmaxwell]

As of now, there are two parallel loops (not including the sound module).

NANONIS LOOP:

• Current
• z pos write
• z pos read
• frame properties
• safetip signal, etc.

HAPTIC LOOP:

• Planing
• Current-Force conversion
• Plunge-depth
• Reframing
• Graphing/Data

The haptic loop seems to be fine running as fast as possible. The nanonis loop feels like it will be fine running as fast as possible (assuming total loop lag time is <~25 ms).

The question is whether or not one VI is running slowly in the Nanonis version or if they all are. If only one or two are running slowly then an analog solution may be on the table.

[freemanmaxwell]

To speed up the nanonis loop, it may be possible to:

• read the frame properties only once
• ignore safetip signal
• stop reading z (I think this is unnecessary)
• read current via analog signal
• write z via analog signal

[freemanmaxwell]

When hardness is set to 0.7, even extreme delays (I've tested up to 100 ms) are usable. Hardness above 0.8 seems to cause feedback. Playing with the max force might yield a more usable/harder curve, but while 0.7 isn't ideal, it isn't awful either.