I can think of two options both require some thought and effort to make them work for your report.
1) While we usually try very hard to avoid using portals in reports, sometimes it's the only practical way to get this to work. Base your report on Device and include portals for each of the Join Tables. Make these portals many rows taller than the largest possible number of related records (This is why we try to avoid this approach) and set them to slide up | Resize enclosing part.
Key facts about sliding layout objects:
- It's only visible in preview mode and when you print/save as PDF...
- All layout objects below and in the same layout part as the slide/resize field need to also be set to slide up and resize.
- Objects in headers and footers will not slide.
- Portals will shrink/slide to fit the number of rows of records, but fields within the portal row will not shrink/slide.
- Consistent side borders are difficult to achieve with sliding fields.
2) Make all your join tables different occurrences of the same table and base your report on this table. This avoids portals, but can make design of your report layout very tricky as you will need to include fields from all of the other tables. Sometimes you end up placing fields from different related tables on top of each other. Since only one table other than Device is linked to any one join table, all the "layered" fields save one will be empty for any given record. In other cases, you can place the fields above/below each other but use slide/resize to eliminate the unused space for fields that appear empty because there is no related record from the specified field for that record in the join table.
Handling the label text for these related fields is an extra challenge. You can use conditional formatting to hide layout text that does not apply to a given join record if you layer the label text just like the fields or you can use calculation fields in the related tables to provide the label text and then they can slide up just like the other fields.
Note: a combined join table would use separate foreign key (ID) fields for each of the tables to keep separate the links to each table.