Footprint Position File X coordinates suddenly negative

OK, I’ve probably done something dumb, but I can’t figure out what’s going on with the footprint position files for PCB manufacturing. I’ve done about four or five assembled PCB orders, no problems…until suddenly “bam” the files don’t work anymore.

So the problem is that suddenly the X coordinates in the output POS file went negative. I’ve tried moving the Drill and Place Offset around to match an older POS file that does work…but that results in the X coordinates being backwards. (Y coordinates are perfectly fine.) FWIW the Drill and Place offset is on the top left of the PCB, though I’ve tried the other corners–and left field, too–with no success.

JLCPCB’s website simply fails to preview the parts placement with an invalid POS file.

I was able to do a search-and-replace in the POS file (removing all of the “-” signs from the X coordinates)…and then JLCPCB accepts the file, with the components in the correct place (even if half of them are oriented incorrectly). But what in the world changed?




Application: KiCad
Version: 5.1.6-c6e7f7d~86~ubuntu18.04.1, release build
wxWidgets 3.0.4
libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-101-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
Boost: 1.65.1
OpenCASCADE Community Edition: 6.9.1
Curl: 7.58.0
Compiler: GCC 7.5.0 with C++ ABI 1011

Build settings:

With which versions have you done it before ? There was a bug report and a bugfix of a discrepancy between .CSV and .TXT output of the position file, maybe you are using the fixed version now, therefore it is different.

Link to bug report:

1 Like

Humph, I think you hit the nail on the head. I was pretty sure that the problem occurred when I updated to 5.1.6…while I did one successful JLCPCB assembly order after the update, there were no parts on the underside of the board (thus this did not apply).

So. Yet another thing to fix before the files can be used @ JLCPCB…

So are you saying that JLCPCB depend on the positions being wrong?

I guess so. Because with the new files, the component placement preview does not work at all. I wouldn’t feel comfortable submitting an order like that.

What happens if you place an auxiliary origin bottom left?

I’ve tried all four corners of the board, as well as arbitrary locations (trying to get the X/Y coords to match the old file)…all with no success. In each and every single attempt I tried, the component placement preview simply did not display any parts. (I verified that the auxiliary origin was changing the coords in the output POS file.)
Because of that, I’m suspecting that if there are any errors, or parts “out of range”, JLCPCB’s component placement preview internally errors and fails to provide a preview.

As I mentioned, the only solution was to do a find-and-replace to remove all of the “-” signs from the POS file’s X coord, with the auxiliary origin at top left…and then suddenly the component preview works.

I will note that the forum thread resulting in the “bugfix” resulting in this now-issue…never mentioned an actual problem with a file being rejected as invalid or anything of that nature. The thread appears to be more of an observation of a discrepancy, not an actual problem: Postive x-coordinates instead of negative values in CSV pick and place file

At least to me, this counts as an actual problem. Because in several of my projects, all of the SMD parts are on the bottom layer (due to a large part on the top layer). And now not only do I have to manually edit certain parts’ rotation, I also have to blanket-modify the entire X column before I can submit an order…

I found this thread about Altium, which at the end says that Pick positions are from the top side always. :grimacing:

It seems that since the .pos file doesn’t include the board size, when flipping a board, the initial reference zero is still kept i.e what was bottom left is now bottom right and the X coordinate will become then be negative. This suggests that the EDIT current /EDIT behaviour is correct.

I raised this as an issue

1 Like

@kcd_DDesign, @cal-linux Some thumbs up on GitLab perhaps?

Will do. Thank you for creating the issue.

A commit has been made into the 5.1 branch

Now you need to know your assembly house preference

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.