Slow rise times on an arbitrary waveform? (AFG31022)

We have a test solution using a 31022 to generate 2 test waveforms while also triggering a 3022 to provide sync to some cameras. The waveforms are using a sample frequency of 1MHz and are a few thousand samples long. It's essentially digital, in that we go from low (0V) to high (4.5V).  The output from the AFG seems to take close to 8 or 9uS to fully transition from 0 to 5.4V. The curve isn't quite a straight line but the scope we tested with shows it to be noisy and almost a straight line- slightly steeper at first and then leveling off for the last uS.  (I'll grab a scope shot and post it as a followup).

To see if this happened on every waveform, I set the unit to run a 20KHz waveform (similar-ish to our test waveform) and watched that on the scope.  That fully transitions from 0 to 4.5V in under a uS but has severe ringing just before it goes high and then afterwards.  The arbitrary waveform doesn't ring.

So this is unexpected and weird, and the slow transition in arb mode is a problem for us.  We're trying to time the response on a device and it's hard to know at what point we should consider low and what point is high.  Microseconds count in this application.

Questions:  ??

1) Is there a setting like output impedance that might matter?  We see this whether the AFG is connected to our test setup or if it's solely connected to a scope through a probe.

2) Is this something which has been seen, reported and fixed so that we should be applying firmware updates?

Thanks!

I'll update the thread, as I have a workaround and am talking with the experts at Tek via email.

The command set does include a function 'SOUR[1|2]:PULS:TRANS:LEAD {n}' to change the leading edge rise time and a corresponding 'SOUR[1|2]:PULS:TRANS:TRAIL {n}' command.  The idea is that instead of letting the AFG pick some slope based on your waveform, you can just set it to be whatever time you want with the minimum being 8 nS.  That sort of works and sort of doesn't.  

In our application we have one waveform that for example, has 4000 points that represent 20 mS in time. The rise time on these edges was about 7 uS - *way* too long. The solution was to add a driver layer that saw we were about to write 4000 points, then decide we could duplicate each point 32 times and still fit into the 128K RAM. It builds a new waveform with each point replicated as many times as it can and still fit, then ups the sample rate accordingly.  Using that trick I got the rise time down to 160 nS.

I have to believe that others have run into the same issue, so it seemed reasonable to share our solution so far.