Make QSRV aware of waveforms which are strings

[ericonr]

This is necessary so these records are served as NTScalar with string value, instead of NTScalarArray with char[] value. This also simplifies clients, since they won't have to convert char[] into strings themselves.

[jwlodek]

I wonder if we should consider making use of https://epics.anl.gov/base/R7-0/6-docs/lsiRecord.html instead of wavforms for these? It would mean base 3.15+ would be required, but 3.15 has been around for a long time now. For example, a recent update to the sscan module switched all character array waveforms to lsi/lso: epics-modules/sscan#36.

[MarkRivers]

I wonder if we should consider making use of https://epics.anl.gov/base/R7-0/6-docs/lsiRecord.html instead of wavforms for these?

Yes, I think that is the best solution. I think that no longer supporting 3.14 in new releases of ADCore is fine.

[ericonr]

Ah, fair point! Should the device support for lsi/lso remain the same? I can try to rework the PR in this direction.

[MarkRivers]

Should the device support for lsi/lso remain the same?

Yes, it should be the same.

[ericonr]

ADCore/ADApp/Db/NDPosPlugin.template

Lines 14 to 29 in 3f74bad

	record(waveform, "$(P)$(R)Filename")
	{
	field(DTYP, "asynOctetWrite")
	field(INP, "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))NDPos_Filename")
	field(FTVL, "CHAR")
	field(NELM, "1000000")
	}
	record(waveform, "$(P)$(R)Filename_RBV")
	{
	field(DTYP, "asynOctetRead")
	field(INP, "@asyn($(PORT),0)NDPos_Filename")
	field(FTVL, "CHAR")
	field(NELM, "1000000")
	field(SCAN, "I/O Intr")
	}

The size used here is much bigger than the max of 32767 supported by lsi. Should these maximums be reconsidered, or are they necessary and so we should keep waveforms for some cases?

I think the same goes for any records which can receive direct XML or JSON data...

Is it better to move to lsi where able, and keep waveform where we might need bigger strings? Or should we be consistent and have a single type?

[MarkRivers]

I am having second thoughts about switching to lsi and lso. The reason is that it will require changing all OPI screens that use the waveform records for long strings because lsi and lso require that the PV in the OPI be specified with the .VAL$ attribute. Here is an example:

The first line waveform record is holding a long string, and the PV in the OPI file does not have the .VAL$ attribute. It works fine.

The second and third lines are pointing to the same lsi record. On the second line PV is not specified with .VAL$. Note that it only displays 40 characters. The third line uses .VAL$ and it displays more than 40 characters.

It will be a lot of work to change the OPI displays, particularly since the PVs in ADCore are used in many other modules outside of areaDetector.