bug in syntax checker

Hi,

I prepared an simpler test without the GUI, running in batch mode.

I start the batch file from a CMD window in the folder where run_problem2.bat and problem2.net is in.

run_problem2.bat contains:

@echo off
rem change the path to your loacation!
rem remove rem on test case!
rem see log file: problem2.log!
rem
rem !not working! in: LTspice 24.1.9 (x64)
C:\DevApp64\LTspice\LTspice.exe -b problem2.net
rem
rem worked in: LTspice XVII 17.0.36.0 (x64)
rem C:\DevApp64\LTspice-17_1\XVIIx64.exe -b problem2.net
rem
rem worked in: LTspice IV 4.23I
rem C:\DevApp\LTspice-4.23I\scad3.exe -b problem2.net

problem2.net contains:

* !not working! in: LTspice 24.1.9 (x64)
* worked in: LTspice XVII 17.0.36.0 (x64)
* worked in: LTspice IV 4.23I
V1 V 0 0
I1 V 0 tbl=(
.include problem1.pwl
+)
.dc V1 0 3 100m

problem1.pwl contains:

+1,3,
+2,9,
+3,81

From the generated log files problem2.log you can see that it is not working in 24.1.9 but was working in the older versions 7.0.36.0 and 4.23I!

Your new "extended syntax check" brakes the universally understood functionality of an ".include"!

The fault is that it is run before the file was included and that it is individually also run on on each file used (main netlist an all files stated in ".included" or ".lib").

It must only be run on the fully expanded netlist!

The faulty behavior is not the fault of the GUI.

HI haubmi ,

I believe this is now supported by the file parameter for a V or I source. The file parameter (or scopedata) in V and I sources is new, and enables very fast reading of large datasets (up to 2GB). This is not an effort to "[break]" LTspice, but an effort to improve its functionality for how many use this function—grabbing output of some function generator, be it benchtop or computational. 

mike

Hi MStokowski, thanks for treeing to help, but the V or I source functionality (PWL file=) you mention is for time dependent data only, that existed also in previous versions (except the doubtful scopedata= "new feature") and is also sort of broken now (see my other bug report "another bug in syntax checker regarding PWL file"). This bug report is about voltage or current dependent current or voltage sources. You can think of a nonlinear resistance or trans resistance. E.g. you could bring digitized data sheet curves into your simulations. But in general the "new extended syntax checker" breaks the universal functionality of ".include" that worked before, just for showing the line numbers and original text in the "new extended syntax checker". So it does not improve any functionality of the simulation engine!

Hi haubmi ,

Sincere apologies. I see I misspoke. tbl=() is supported for I sources.

I don't see that tbl=(.include) works in XVII (17.0.37) when used in a schematic. Trying command line…

Do you see a break at 17.0.36 vs …37?

If so, this is not syntax checker related, as 24.1 represents the new syntax checker. It is possible you have found a very old bug.

mike

Hi haubmi ,

This:

tbl=(.include problem1.pwl)

doesn't work in LTspice IV.

Do you have a simple schematic where .include works in as a tbl=() in LTspice IV?

mike

Hi mike,

can you provide a link to 17.0.37 so I could test with this, I only have 17.0.36.0?

".include" is a dot command, and in every SPICE and also in the LTspice simulation engine, a command must be the first on a new line.

As far as I know there is no way to enforce line breaks in symbol attributes in the GUI.

So we must resort to direct netlist text in the GUI or use a sub circuit text file.

I have prepared a simple test cases here:

_problem3.zip

problem1.asc does not run in 24.1.9 but runs perfectly ok in 17.0.36.0 and older version.

Your team creates LTspice unique, artificial syntax exceptions, to just allow ".include" only in some text positions, just to make it easier for the "new extended syntax checker" to show the file, a line number and the original text. The old but good syntax checker showed only the erroneous text after full expansion, but did not make any restriction to normal SPICE syntax! In regular SPICE syntax ".include" can be anywhere in the input stream! As long it is the first command on a new line it can have any text, that if inserted in the calling file would be SPICE syntax conforming.

I have included some useful applications of .include, I can think of, at the moment (there may be endless more):

other_cases1.asc shows E and G sources with a table not running in 24.1.9 but running perfectly ok in 17.0.36.0 and older version.

other_cases2.asc shows how to have frequency dependent data in an .AC but not running in 24.1.9 but running perfectly ok in 17.0.36.0 and older version.

FREQ.asc shows that the FREQ= functionality used in other_cases2.asc was and is principally still available in 24.1.9.

Unless you can find a way that the "new and extended syntax checker" can refer to the file, line number, original test, indirectly and not disrupting the .include feature, I propose to fall back in suspicions cases to the old but good syntax checker or provide a way the user can disable the "new extended syntax checker". 

Hi haubmi ,

haubmi said:

".include" is a dot command, and in every SPICE and also in the LTspice simulation engine, a command must be the first on a new line.

I know, which is why I was scratching my head. But, you had below in your schematic:

tbl=(.include file)

This particular statement is almost readable, and at the top, so I started there…

Nevertheless, I have now opened your new (far simpler and intelligible) problem1 file and confirmed that indeed, as you stated in your earlier version:

The form: 

I1 V 0 tbl=(
.include problem1.pwl
+)

Does work in earlier versions of LTspice, but not 24.1. I will check on this.

As far as B sources supporting the non-beginning-of-line include: this is a new feature added to 24.1 to answer some requests. Is it non-ideological re a spice directive not at the beginning of a line. Maybe. I think that is part of your question. Also, if it works for B sources, why not for I, G, and E sources? That is a legitimate question. Will find out.

haubmi said:

old but good syntax checker

(Stated as known fact without a meta examination of the code; so subjectively.) We are often are told the old syntax checker was better because it was libertarian. How often did old LTspice just make arbitrary decisions (without warning) based on fuzzy or ill-formed syntax? Sometimes, you don't know what you don't know. That said, this might be a case where the syntax should be legitimate in the new system. I will find out.

I am examining the other issues.

Thank you for your patience.

mike

please set text size to 16

haubmi said:

please set text size to 16

Ah. Thanks. Much better.

mike

Hi haubmi ,

For an upcoming version, we will expand the syntax and make sure it is backwards compatible.

To wit:

The functionality of your I5 subcircuit:

.subckt I-sub2 1 2
I1 1 2 tbl=(
.include problem1.pwl
+)
.ends I-sub2

Will be restored in an upcoming version, so that it works as if:

.subckt I-sub1 1 2
I1 1 2 tbl=(
+1,3,
+2,9,
+3,81
+)
.ends I-sub1

No syntax error.

Also, we are expanding the file include ability currently supported by B sources to I, G and E sources, namely table=() or tbl=() parameters. This will allow the" tbl=(.include filename)" syntax or "tbl=("filename") syntax.

Furthermore, the confusing "###" syntax errors had already been fixed for the upcoming version. This was related to expanded unicode support and the fact that the offending syntax crossed line breaks. The "###" is an inexpensive way to say "this multiple-byte character, which I cannot necessarily render".

haubmi said:

other_cases2.asc shows how to have frequency dependent data in an .AC but not running in 24.1.9 but running perfectly ok in 17.0.36.0 and older version.

I still have to examine this one.

Thank you for your patience,

mike