Oscilloscope trigger 'first run' issue

[mnfisher]

A minor bug - that caused me a moments head scratching.

A simple demonstration program - debug -> go.

osx.fcfx

(6.92 KiB) Downloaded 38 times

On the oscilloscope click 'use trigger' then click 'arm'

First time of running - nothing happens - trigger doesn't fire. Changing anything (dragging the 0V marker down for example) - causes the trigger to fire and all subsequent 'arming' works AOK. It then works perfectly until FC is shutdown and the program is reloaded.

It's a brilliant tool - and I've barely scratched it's surface It would be a nice feature if changing the scale - zoomed the display in real time?

Martin

[p.erasmus]

First time of running - nothing happens - trigger doesn't fire. Changing anything (dragging the 0V marker down for example) - causes the trigger to fire

This was reported in in the past
It also has a tendency to trigger if you change the time scale .I found that doing that once then the scope will function all the time until you close FC and reopen again

[Steve-Matrix]

Thanks for the clear report. I will investigate.

[Steve-Matrix]

I've looked into this and I think it is working correctly. But the way the triggering works is perhaps not explained very well in the wiki. I will try to explain a bit more here:

Without the trigger, you should see the waveform when the simulation is run. With the trigger, the waveform will show only when trigger condition is fulfilled.

When your project loads, the 0V setting of that trace is set to the middle of the vertical scale. The trigger-point is also set to the middle of the vertical scale (as well as the centre of the horizontal scale) as shown by the two arrows. The "sweep type" is set to "single", the "edge event" is "rising", and the "source channel" is "CH1".

Clicking "use trigger" and then "arm" will make the oscilloscope wait until the trigger condition is fulfilled. This will occur when the oscilloscope detects a rising edge in the centre of the vertical axis. But this is currently not happening. The waveform is oscillating between the "0V" position of the trace and the "5V" position of the trace, but there is no rising edge happening at the centre point. If you move the trigger point down or the 0V marker for the trace up, then the rising edge will be detected and the waveform will be shown.

The horizontal scale trigger marker allows you to see the waveform(s) before and after the trigger event has been detected.

The wiki entry could be improved to make this clear as it currently fails to explain the vertical trigger marker's function.

Being picky, I would suggest if the horizontal trigger is at *exactly* the same position as the lowest (or highest) point of the waveform (as it is when this project is first loaded) then this should trigger the trace to be drawn. At the moment, however, a rising/falling edge is only detected once the waveform has moved away from its highest/lowest position.

[mnfisher]

I've looked into this and I think it is working correctly.

It might be - it's just not quite what I'd expected - Trigger is for 'rising' edge on Ch1 - this occurs every 'pulse' - and should be triggered when this occurs. The fact that it only doesn't do this on first 'run' is odd - it then works on any 'trigger event' until after closing / reopening FC, when first fails again?

Martin

[Steve-Matrix]

I don't believe it failing on a first run. It's because the trigger position is not within the waveform. If you set it up as described but drag the "0V" marker up instead of down, the trigger will still not occur.

It will only trigger if the trigger position (i.e. the vertical arrow on the right of the display) is set to a position within the range of the waveform. When I tried loading your project, the trigger position is set to the same position as the lowest point of the waveform, so there is no rising edge to be triggered.

You will need to either move the waveform lower (drag the 0V marker down) or move the trigger marker higher (drag the arrow on the right up) for the trigger to be within the waveform.

[mnfisher]

I'd read the trigger as being on a rising edge of Ch1 (so B0 goes from 0V to 5V) I think I see what you mean - however on subsequent 'arms' it either displays from the trigger point or fills the display (without having to move the 0V line or otherwise). To demonstrate - stop the simulation and change the delay time from 10ms to something else - restart simulation (note that oscilloscope closes (itself) and on re-opening the display is cleared) Click 'arm' - and display of pulse starts at 'trigger' point or at left of display on subsequent 'triggers'

There is another minor issue - I'll post some more details in the VC topic.

[Steve-Matrix]

Hi Martin,

I've tried following your instructions and I'm not seeing the problems that you are, but I am keen to get to the bottom of this and understand why we are experiencing different things. I am using the latest build (v9.3.1.36 dated 1st Nov 22). Here's what I am doing:

1. Open your file in Flowcode
2. Start the simulation - the oscilloscope shows a repeating trace

   

   osc1.png (42.65 KiB) Viewed 1385 times

3. Click "use trigger" and the oscilloscope clears
4. Click "arm" and the oscilloscope remains clear
5. Stop the simulation and edit the delay icon (to 200ms) and restart - the oscilloscope does not close, and remains clear (it is waiting to detect a transition)
6. Drag the black arrow up so the trigger point is within the range of the trace and the trace is shown. It is in "single sweep" mode so the trace remains and you would need to press "arm" again to reactivate the trigger.

   

   osc triggered.png (42.11 KiB) Viewed 1385 times

I don't know why your oscilloscope is disappearing - that is odd.

Regarding the trigger point position, I've tried to explain things a bit clearer in the following diagram for the benefit of anyone else having issues with the triggering on the oscilloscope.

osc trigger explanation.png (199.49 KiB) Viewed 1385 times

I think some of the initial confusion could be because when the project is first loaded, the trigger point is at the same position as the low point of the waveform and at this point the rising edge is not seen (it is only seen when the trigger point is above the low point, and not equal to it). I have experimented with this and changed it so that in v10 the edge transitions will also be detected at the high and low points of the trace.

[mnfisher]

Thanks Steve,

Yes - that's clear - I wasn't even considering a 'trigger' point on the vertical axis (and hadn't noticed it ) I would expect the 'curve' to start at the trigger point, maybe - or starts recording prior to the trigger?

I'm finding the oscilloscope 'closes' when I restart 'debug'. So - when I start (click go) - then oscilloscope window is replaced by the 'Simulation debugger' window. Note it's not behind it - I can drag it around and it's not there. If I click 'Stop' - the simulation debugger window reverts to 'oscilloscope' window. To get the oscilloscope whilst debugging - I need to do View - oscilloscope.

Strangely - when I run it this evening I find the 'simulation debugger' window (called 'watch' in view) and the oscilloscope window are mutually exclusive. When I open one it replaces the other (on the same 'footprint'). This works correctly in v8and I'm sure worked correctly before. System isn't short of RAM - is there a setting I've tweaked?

As a question - the scale is, say, 100ms per div - what is a div? For example if I set this as 100ms/div and a delay of 50ms a high pulse 'lasts' 3.5 columns running at 1hz and 5 (and a little bit) running fast - which would imply 100ms for a complete horizontal sweep? I know timings are not accurate (but are pretty damn good!) - but shouldn't this be 10ms/div?

As an aside it would be neat to allow a channel to alter the x-axis values - Lissajous figures would make a cool demo?

Martin

[Steve-Matrix]

Yes - it does record and show events before the trigger occurs.

Regarding the oscilloscope closing issue, your description has helped and I think I may know what's going on. I think at some stage the oscilloscope window and the simulation window have become docked together (or tiled together) in the same pane. You might find there are tabs on the combined window that you can drag to separate the windows.

But if this is not the case then it could be the registry controlling the window positions has become corrupted for some reason. In that case, can you please export and PM me your Flowcode registry settings (the whole HKEY_CURRENT_USER\Software\MatrixTSL\FlowcodeV9 branch) so I can try to replicate your situation here and determine a fix for you.

You are correct that the x scale timing seems wrong, both in simulation and in ICD mode. A "div" is intended to be one of the smaller squares as it is with the horizontal scale, so the whole width of the oscilloscope would be 10 divs. In my experiments, the x-scale is accurate when using the oscilloscope in ICT mode (that is when using the "Ghost" option when connected to E-Blocks showing the trace for a running program on hardware).

However, running the same project via ICD (i.e. executing a project running on E-Block in ICD mode), a scale saying 10 ms/div is actually showing the trace at 500 ms/div, so a factor of 50 out! That's the same factor at other scales. For simulation I get similar results to you.

I think the conclusion is that the oscilloscope scale is indicative only unless using it in straight ICT Ghost mode. That should not stop it being used (just disregard the numbers on the x-axis scale).

And good suggestion about channels altering the x-axis values. I don't think that's practical to do with the current oscilloscope, but you could achieve something similar using an X/Y chart component or (in v10) writing directly to a canvas primitive.