Inconsistencies at drawing with %pl

I've written the following code, which draws in principle the wished graph. All used variables and expressions are declared in the correct manner.

! Opening MDI-window     07.03.18       
      i=winio@('%sp&',winx,winy)
      i=winio@('%pv%`fr&',winb,winh)
      i=winio@('%ca[cross section and concrete behaviour]&')
      i=winio@('%lw[owned]',ctrl)
!c---Display a window containing the graph.
      iw0=winio@('%sp&',plox,ployo)
      iw0=winio@('%pv%aw&',ctrl)
      iw0=winio@('%ww[no_border]&')
      iw0=winio@('%`bg[white]&')
      iw0=winio@('%ca[concrete behaviour acc. to DIN EN 1992]%pv&')
      CALL winop@('%pl[title='for ULS: parabola-rectangle with f_cd']')
      CALL winop@('%pl[y_min=0.,y_max=1.]')
      CALL winop@('%pl[x_min=0.,x_max=3.5]')
      CALL winop@('%pl[x_axis=Verzerrung]')
      CALL winop@('%pl[y_axis=Spannung]')
      CALL winop@('%pl[dx=0.5,dy=0.1]')
      CALL winop@('%pl[n_graphs=2]')
      CALL winop@('%pl[width=2,width=2]')
      CALL winop@('%pl[pen_style=0,pen_style=2]')
      CALL winop@('%pl[link=curves,link=curves]')
      CALL winop@('%pl[colour=red,colour=blue]')
      CALL winop@('%pl[symbol_size=2,symbol_size=2]')
      CALL winop@('%pl[symbol=0,symbol=11]')
!C first variation
      CALL winop@('%pl[x_array]')
      iw0=winio@('%pl',plopix,plopiy, &
        ist,xData(1:ist,1),yData(1:ist,1),yData(1:ist,2))

But there are some inconsistencies: x-axis-label is written at the right end of x-axis (xmax) y-axis-label is centered at the y-axis Why that? It would be fine, when x-axis-label is also centered!

!C second variation
      CALL winop@('%pl[x_array,x_array]')
      CALL winop@('%pl[independent,independent]')
      iw0=winio@('%pl',plopix,plopiy, &
        ist,xData(1:ist,1),yData(1:ist,1),xData(1:ist,2),yData(1:ist,2))

Both variations should draw the identical graph. But there are more inconsistencies: x-axis-label is written at the right end of x-axis (xmax) y-axis-label is written at the upper end of y-axis (ymax) At the blue(second) curve (...,2) a line is drawn from the last data-point (xmax,ymax) to the origin! Why that?? The data for the first and second variation is the very same.

Has anybody an idea to correct these inconsistencies.

At last, I'd like to have a grid at the graph. What is to do?

The native %pl is still a work in progress and it is quite possible that a number of these issues have been fixed in ClearWin+ for the next release.

Hi FK, There are been a fair bit of discussion of these issues over the past year. For now, the best way to place you axis labels is via a call back function attached to the %pl using draw_characters@ For grid lines use:

call winop@('%pl[gridlines])

The grid lines option became available in release 8.2

I would use link=lines rather than link=curves, the smoothing algorithm (spline or poly?) does seem to have problems in some cases.

Ken

At first I've tried 'link=lines'. But in this case the data points are linked with parabolic curves !!! I was very surprised. Therefore I've tested 'link=curves' and must realize, that the points are linked with a straight line, as desired. Here is another problem at %pl. Ken also mentions problems with the 'smoothing'.

And here a further example as aforesaid:

! Opening MDI-window     07.03.18       
      i=winio@('%sp&',winx,winy)
      i=winio@('%pv%`fr&',winb,winh)
      i=winio@('%ca[cross section and concrete behaviour]&')
      i=winio@('%lw[owned]',ctrl)
!  Drawing a simple XY Graph
      iw0=winio@('%sp&',plox,ployo)
      iw0=winio@('%pv%aw&',ctrl0)
      iw0=winio@('%ww[no_border]&')
      iw0=winio@('%`bg[white]&')
      iw0=winio@('%ca[cross section and reinforcements]&')
      CALL winop@('%pl[title='concrete cross section']')
      CALL winop@('%pl[y_min=0.,y_max=2.]')
      CALL winop@('%pl[x_min=-0.5,x_max=+0.5]')
      CALL winop@('%pl[x_axis=cross section width]')
      CALL winop@('%pl[y_axis=cross section height]')
      CALL winop@('%pl[dx=0.1,dy=0.1]')
      CALL winop@('%pl[n_graphs=3]')
      CALL winop@('%pl[width=2,width=2,width=2]')
      CALL winop@('%pl[pen_style=0,pen_style=0,pen_style=0]')
      CALL winop@('%pl[link=curves,link=none,link=none]')
      CALL winop@('%pl[Colour=black,colour=blue,colour=red]')
      CALL winop@('%pl[symbol_size=4,symbol_size=4,symbol_size=4]')
      CALL winop@('%pl[symbol=1,symbol=11,symbol=7]')
      CALL winop@('%pl[x_array,x_array,x_array]')
      CALL winop@('%pl[independent,independent,independent]')
      iw0=winio@('%pl',plopix,plopiy, &
          IPLD,xData(1:ipld,1),yData(1:ipld,1),xData(1:ipld,2),yData(1:ipld,2),xData(1:ipld,3),yData(1:ipld,3))

Description: A concrete cross section with two reinforcements (prestressed and not prestressed) is to be drawn. The corner points of the concrete (..,1) are to be linked with a solid line; for the reinforcements (..,2) (..,3) only the points are to be marked. But what happens: only the first data (...,1) is drawn! At the example before (second variation) the second data (...,2) is drawn, at least. Why here the second and the third data is not drawn? By the way, for a complete presentation of the cross section data there are three further data ranges to be drawn, total n_graphs=6. How this is able to work? Already the graph of two data-ranges creates problems!

Some further questions: x-axis runs from -0.5 to +0.5; y-axis is drawn at origin (0,0). This causes, that the y-axis is drawn centered through the shown section. Is possible to move the y-axis at point x=xmin?

pen_style=0 → solid line; pen_style=2 → dashed line; (found in examples) pen_style=1 → ??? pen_style=3 → ??? pen_style=4 → ??? ...

Is it possible to replace the 'clear' text and numbers with variables. e.g. xname='cross section width' CALL winop@('%pl[x_axis=xname]') or miny=0. maxy=2. CALL winop@('%pl[y_min=miny,y_max=maxy]')

Is it possible to link a small working code example ? Say with a dropbox link or similar. Reporting the version of FTN95 and also the .dll's you are using is also important for understanding the version of %pl that is causing these issues. Otherwise it is difficult to identify the problem and comment.

By your remarks I suppose, that the most of the my prescribed problems results from the used personal edition of FTN95, which is an elder Version (8.1). I've just seen, that FTN95-Version 8.3 is released today. I hope, that a lot of problems are solved in this version. By the way, at the beginning of my programs I'm using INCLUDE <windows.ins>, nothing more.

You may prefer to draw things using the ordinary graphics primitives, thus:

      WINAPP
      OPTIONS (INTL, DREAL)
      PROGRAM RC_SECTION
      INCLUDE <WINDOWS.INS>
      INTEGER, EXTERNAL:: KB_DRAW_FN
      IK = WINIO@('%ca[RC Cross Section]&')
      IK = WINIO@('%gr[white]%ff%rj%10^bt[Draw]', 400, 400, KB_DRAW_FN)
      END
      INTEGER FUNCTION KB_DRAW_FN()
      INCLUDE <WINDOWS.INS>
      CHARACTER*(21) STRING
      STRING = 'RC Beam Cross Section'
      CALL DRAW_FILLED_RECTANGLE@(200,50,300,350,RGB@(200,200,200))
      CALL DRAW_RECTANGLE@(200,50,300,350,RGB@(0,0,0))
      CALL DRAW_FILLED_ELLIPSE@(220,70,5,5,RGB@(50,50,50))
      CALL DRAW_FILLED_ELLIPSE@(280,70,5,5,RGB@(50,50,50))
      CALL DRAW_FILLED_ELLIPSE@(220,330,5,5,RGB@(50,50,50))
      CALL DRAW_FILLED_ELLIPSE@(280,330,5,5,RGB@(50,50,50))
      CALL DRAW_CHARACTERS@(STRING,50,10,RGB@(0,0,0))
      CALL DRAW_LINE_BETWEEN@(190,200,310,200,RGB@(0,0,255))
      CALL DRAW_LINE_BETWEEN@(250,40,250,360,RGB@(255,0,0))
      CALL PERFORM_GRAPHICS_UPDATE@()
      KB_DRAW_FN = 2
      END

Eddie

Thanks for your replies. But they don't help at my problems really.

I've tested the shown example from Eddie, but that's not what I'm needed. The example is pixel-orientated, but all my data is coordinate-orientated. And there are variable cross-sections with shapes of rectangle-, L-, T- or I-profile with very different dimensions. Moreover the numbers of reinforcements differs between 1 and 50.

I have had tested the option 'native', but without any effect. If I must compiling in a 64-bit mode, from where I can get a 64-bit version of the personal edition? (My windows system is a 64-bit system)

Yesterday I've contacted the Silverfrost Company per E_Mail and asked for a new version of the personal edition. Today I got the following message: 'The intention is that there will be a FTN95 8.30 Personal Edition in the next few weeks.'

I hope, that then some problems will be solved. But when I recognize your discussion afore properly, I'm doubtfully.

At last some screenshots of two examples, calculated with the XP-programs. I hope, all is adjusted correctly at the image-server, so that you have a look at the pictures. Example Q1-xx shows the example of a calculated I-cross section, graphics are generated with the 'scigraph-package' from compaq. Example B3-xx shows the course of the stiffnesses for bending and torsion during the calculation, graphics are generated with the 'array viewer' from compaq. https://postimg.org/gallery/1vbxb1apy/ https://postimg.org/gallery/18s6cuwsm/

Quoted from FK_GER I've tested the shown example from Eddie, but that's not what I'm needed. The example is pixel-orientated, but all my data is coordinate-orientated. And there are variable cross-sections with shapes of rectangle-, L-, T- or I-profile with very different dimensions. Moreover the numbers of reinforcements differs between 1 and 50.

I am surprised by your comment, as I would expect that Eddie's %gr approach would be much more suitable for managing the variation in section shape and bar locations. If you want a flexible approach, I would recommend you reconsider what Eddie has suggested.

Dear JohnCampbell, Please, have a look in the following picture https://postimg.org/image/3y40tu0kl/, and then tell me, how to manage this graph with Eddie's proposal. FK

Quoted from FK_GER Please, have a look in the following picture, and then tell me, how to manage this graph with Eddie's proposal. FK I would expect that a suitably developed subroutine library would be more suited to %gr. My FEA graphics system is based on %gr and I would not limit this to be considered as a 'graph'. My comment was a recommendation to consider the %gr alternative.

John